oxlint: better vue support

[Boshen]

Current Situation

eslint-plugin-vue cannot be made fully compatible because it relies on its own compiler, which produces a modified AST for ESLint to traverse.

In Oxc, due to the lack of JavaScript bindings inside Vue templates, rules such as unused variables (and many others) do not work and cannot be implemented.

Proposal

• eslint-plugin-vue will not be a target for full compatibility at this time.
• Implement a custom Vue parser in Oxc that extracts the JavaScript sections from templates.
• Attach these extracted JavaScript fragments to the AST of the <script> tag and pass them through the rest of the linter pipeline.

[overlookmotel]

An alternative approach would be to add Vue nodes to our AST.

I've not looked deeply at Vue, but supporting Svelte's template syntax ({#if ...} etc) would not require too many additions to AST. I'm guessing situation with Vue is probably similar.

One problem with parsing the JS fragments in isolation is that some template syntaxes introduce scopes and symbols. e.g. this introduces a scope, and defines a symbol item within it:

<li v-for="item in items">
  {{ item.message }}
</li>

Linter should:

1. Not flag item in item.message as undefined.
2. Flag items as undefined if no binding items appears above it in AST.

To do that, it needs not just the bits of JS inside {{ ... }}, but also an AST which represents the template syntax, and a scopes tree that matches it.

---

Adding types to the AST may feel like the "nuclear option", but I suspect that any halfway approach will cause other kinds of mess, bugs, and complexity - and ultimately cost us more time than going the whole hog in the first place.

I imagine (hope) that contributors from Vue community (and ditto Svelte etc) would be willing to put in a lot of the work if we agree to support these frameworks as first class citizens.

[Boshen]

An alternative approach would be to add Vue nodes to our AST.

Adding other AST nodes is out of scope for this project.

I'd like to take in an extra dependency in the linter for the transform logic. We should not maintain logic for these other compilers.

[Boshen]

We now have a POC: https://github.com/zhiyuanzmj/vue-oxc-parser

We need to somehow integrated into the linter pipeline

oxc/crates/oxc_linter/src/service/runtime.rs

Line 905 in 15d367a

fn process_source<'a>(

[zhiyuanzmj]

For semantic:

let result = VueOxcParser::new(&allocator, &source_text)
    .parse_for_semantic();
let program = result.program;
let errors = result.errors;

Playground: https://repl.zmjs.dev/vuejs/vue-oxc-parser?main=src%2FMain.vue

[kazupon]

FYI:
@ubugeeei is making a parser (compiler).
https://github.com/ubugeeei/vue-compiler-rs

[ubugeeei]

this is my hobby ;D

[zhiyuanzmj]

vue-oxc-parser using a vue-parser from https://github.com/HerringtonDarkholme/vue-compiler to generate JSX AST for Oxc, Or you can also generate JS AST for Oxc.

[ubugeeei]

Yep! However, that project has been not been active.

So, I tried to rewrite from srcatch as my hobby project.

Feel free for feature requests ;D

[ubugeeei]

Hello. As mentioned above, I’m currently implementing a Vue compiler as a hobby project.

While I was thinking about implementing a few linters as well, I came up with an idea.

Similar to how oxlint absorbed tsgolint, what do you think about providing a standard format for consuming lint results from external CLIs via stdout, and making that part of the plugin system?
I haven’t fully thought through the concrete format yet, but I’d be very interested to hear what the oxlint team thinks about this idea.