To avoid extra overhead of using unimport in js side, most of the component and directive resolutions can happen in the Rust side.

• Research how unimport works on source code;
• Research how unimport gathers the auto-import symbols (across source code and dependencies);
• Research existing Node resolution libraries (import 'x' -> node_modules/path/to/x/index.js) in Rust;
• Ensure we can support Lazy prefixed imports;
• ... define other steps after research.

The possible compilation targets are (excluding DEV/PROD differences):

• CSR;
• SSR;
• Vapor mode CSR;
• TS library;
• Possibly .d.ts generation;

The compiler needs to be able to efficiently support all the targets with some common layer and target-specific implementations.

https://github.com/vuejs/core-vapor

https://vapor-repl.netlify.app/

The project is wonderful.

In other to test and check it more conveniently, I'd like to request a playground, like this one.

I am still not sure how TS is used in the official compiler to generate .d.ts of .vue files. It uses defineComponent in the generated code but I want to find a balance between generating the most optimal code (i.e. omitting defineComponent) and supporting TS definitions.

Spec:
https://github.com/vuejs/core/blob/272ab9fbdcb1af0535108b9f888e80d612f9171d/packages/compiler-sfc/__tests__/compileScript.spec.ts#L1407-L1424

Farm is now 1.0 stable, the Rust plugin(https://www.farmfe.org/docs/plugins/writing-plugins/rust-plugin) are available for community plugin developers too.

We want to develop a Rust vue plugin based on this project, can we have a collaboration. Relative issue: farm-fe/farm#125

Current detection only works for the top-most level. The spec requires nested detection except for functions.

Spec:
https://github.com/vuejs/core/blob/272ab9fbdcb1af0535108b9f888e80d612f9171d/packages/compiler-sfc/__tests__/compileScript.spec.ts#L748-L860

Spec:
https://github.com/vuejs/core/blob/272ab9fbdcb1af0535108b9f888e80d612f9171d/packages/compiler-sfc/__tests__/compileScript.spec.ts#L380-L401

Spec dictates that exports should not be allowed in script setup.

Spec:
https://github.com/vuejs/core/blob/272ab9fbdcb1af0535108b9f888e80d612f9171d/packages/compiler-sfc/__tests__/compileScript.spec.ts#L871-L890

Implement user imports deduplication between two scripts

Spec:
https://github.com/vuejs/core/blob/272ab9fbdcb1af0535108b9f888e80d612f9171d/packages/compiler-sfc/__tests__/compileScript.spec.ts#L261-L275

Example:
https://play.vuejs.org/#eNp9kUFLAzEQhf/KMJcqLNtDb6UIKj3oQUU95lK20zU1m4RMUqPL/neT1K5VSm/hve+RNzM9Xltb7wLhHBfcOGn9ldCys8Z56CHCABtnOpjU0zgRejEdmR8amHywfzIVfFbw9S8ZLy6P4lih58bojWzrLRudfu+FBhDYmM5KRe7Remk0C5xDcbK3Usp83BfNu0DVQW/eqHk/oW85Zk3gkyMmtyOBo+dXriW/t5cvDxTTezQ7sw4q0WfMZ2KjQu64x26CXqfaR1xpe1e2InX7ysvoSfNhqFw0k0PhBaYT3J4Z/bfurJ6VnNADDt8cQ5JX

name should be inferred based on file name.
It may also be a good idea to use file paths as part of name (@/foo/bar.vue -> name: 'FooBar', but the spec has no such requirement.

Spec:
https://github.com/vuejs/core/blob/272ab9fbdcb1af0535108b9f888e80d612f9171d/packages/compiler-sfc/__tests__/compileScript.spec.ts#L1252-L1306

Situation

When using <script setup lang="ts"> we can make assumptions regarding binding types. For instance, we can confidently infer the types of bindings in this example:

<script setup lang="ts">
import { ref, computed } from 'vue'

const foo = ref('Hello')
const bar = ref(1)
const baz = computed<number>(() => bar.value * 2)
</script>

Proposal

fervid can trust the user's TypeScript setup to catch type errors. In the future, when stc is mature enough, it will be used for type inference and checking.

Knowing the binding TS type, we can further optimize the generation of Interpolations and SSR attributes:
const msg = ref('') // string

By having the knowledge of types we can omit unnecessary runtime checks and also ship less code.

Possible implementation

The transformer already detects Vue-specific symbols, such as ref and computed. We can extend the analysis to also visit the value (second priority) or the type annotations (first priority) and store this information along with the BindingTypes.

Considering the fact that TS types are complex and inference may not be trivial, the TS type must be an optional hint for the compiler.
When no such type can be inferred (or when outside TS), the compiler should fall back to default code generation.

hi @phoenix-ru Is support for unplugin already under way? I'd like to be involved if I can.

• Check if template assignments are correct and fix if not;
• Add test cases;

Spec:
https://github.com/vuejs/core/blob/272ab9fbdcb1af0535108b9f888e80d612f9171d/packages/compiler-sfc/__tests__/compileScript.spec.ts#L495-L600

Features I personally find very desirable:

• auto-completion of tag names (regular html and using auto-imports from #24);
• auto-completion of component attributes (VBind and VOn);
• parse error reporting (HTML and JS/TS);
• ...

Spec:
https://github.com/vuejs/core/blob/c0c9432b64091fa15fd8619cfb06828735356a42/packages/compiler-sfc/__tests__/compileScript.spec.ts#L1308-L1424

Problem

The official Vue parser allows self-closing any HTML, but this is not valid by the spec. For example, this:

<template>
  <slot />
  <div class="bad" />
</template>

Using Nu HTML Checker by W3 results in a clear error:

The same happens when parsing with swc_html_parser. The error is being reported and the tag is not being closed:

InvalidHtml(NonVoidHtmlElementStartTagWithTrailingSolidus) <slot />

In addition, this also messes up the DOM Tree stack, which is the actual problem here.

Possible solution

All NonVoidHtmlElementStartTagWithTrailingSolidus should be considered a hard error.

Nice-to-have

It would also be nice to do RegEx search-replace as a utility in fervid.
Another option is to parse the HTML and only apply this fix to where the NonVoidHtmlElementStartTagWithTrailingSolidus problem is encountered.

Make module generator produce getters and setters for certain bindings

https://github.com/vuejs/core/blob/a41c5f1f4367a9f41bcdb8c4e02f54b2378e577d/packages/compiler-sfc/__tests__/compileScript.spec.ts#L16-L52

Writing SFCs using the default JS compiler and https://github.com/unplugin/unplugin-auto-import produces not-so-optimal code.

Take this for example (playground):

<script setup>
const msg = ref('Hello World!')
</script>

<template>
  <h1>{{ msg }}</h1>
  <input v-model="msg" />
</template>

Correct binding type of msg cannot be properly inferred, which leads to compiler generating unref(msg), which in turn has runtime cost.
In addition to that, extra build step is needed to properly auto-import the ref.

A better approach would be to add a ref/computed/etc. vue-specific imports whenever their usage is detected. It is much cheaper and more beneficial to do so in the SFC compiler than in any other tool.

Steps:

• Detect stray known symbols usage. This can happen during regular transform pass;
• Inject non-prefixed imports (e.g. import { ref } from 'vue' instead of ref as _ref);
• Respect user-defined imports (e.g. import { ref } from './custom-path' should not auto-import).

At the moment of writing, GitHub CI has no ARM-based hosted runners for public repositories.

As a follow-up from #12, we should add tests for ARM builds using QEMU.

• #14
• #17
• #18
• #19
• #20
• #21
• #22
• #23
• #30
• Make sure test spec is up-to-date with https://github.com/vuejs/core/blob/main/packages/compiler-sfc/__tests__/compileScript.spec.ts