☂️ Oxlint JS Plugins Milestone 2

[overlookmotel]

First version of Oxlint JS plugins is out in the wild 🎉 ! (docs)

However, we still have a lot of ground to cover. This is an umbrella issue covering the next phase of development.

Priorities

The focus of milestone 2 is:

1. Filling in the gaps in our API, to cover all of ESLint's API surface.
2. Support JS plugins in language server (IDEs).
3. Support framework plugins (React, Vue, Svelte etc).
4. Fix bugs.

Overall aim is to make Oxlint able to run any (or almost any) ESLint plugin without modification.

We should prioritize APIs which have highest impact in terms of enabling more plugins to work "out of the box".

Performance

Performance is NOT a priority at this stage. If we can get a feature working quickly by pulling in a dependency (even one that's not well-optimized), we should do that. We can loop back and work on perf in Milestone 3.

However, any opportunity for future performance improvements should be documented - either by opening an issue, or by adding a comment to the code e.g.:

// TODO: Currently we do X for ease of implementation,
// but we should reimplement as Y later for better performance

Stubs and types

First step is to stub out the whole API:

• Stub out all ESLint Context methods that we are currently missing as dummy methods that throw an "unimplemented" error (similar to unimplemented methods of SourceCode). feat(linter/plugins): stub out all Context APIs #15479, feat(linter/plugins): implement deprecated SourceCode#getJSDocComment method #15653
• Add all missing properties of Context (as getters which throw "unimplemented"). feat(linter/plugins): stub out all Context APIs #15479
• Fill out TS type defs for Plugin - to include all properties, whether implemented or not at present.
• Fill out TS type defs for Rule - to include all properties, whether implemented or not at present.
• Fill out TS type defs for RuleMeta fix(linter/plugins): fill in TS type def for RuleMeta #15629
• Fill out TS type defs for Diagnostic fix(linter/plugins): add types for suggested fixes #15636

Missing APIs

First priority on APIs is to implement APIs which are used in "fix code"-type rules (not stylistic/formatting rules).

• Context#cwd property Linter plugins: Add cwd property to Context #14777
• Options Linter plugins: Support options for JS rules #14825
• Settings feat(linter/plugins): allow js plugins to access settings #14724
• Scope analysis Linter plugins: Scope analysis #14827
• Context#languageOptions
  • sourceType - from AST feat(linter/plugins): implement context.languageOptions #15486
  • ecmaVersion - static value feat(linter/plugins): implement context.languageOptions #15486
  • globals - already parsed on Rust side from config - send over to JS
  • parser - not sure how to deal with this
  • parserOptions feat(linter/plugins): implement context.languageOptions #15486
• Deprecated APIs (getSourceCode etc) feat(linter/plugins): implement deprecated SourceCode tokens methods #15645, feat(linter/plugins): implement Context#get* deprecated methods #15606
• SourceCode#getNodeByRangeIndex method feat(linter/plugins): implement SourceCode#getNodeByRangeIndex #16256
• Suggestions (requires language server support to be useful)
• BOM Linter plugins: Handle BOM #12526 (surprisingly tricky)

Token APIs

2nd priority is to add support for stylistic / formatting rules.

• Support token-related SourceCode APIs Linter plugins: Token-related SourceCode APIs #14829
• SourceCode#isSpaceBetween method - feat(linter/plugins): implement SourceCode#isSpaceBetween #15498, refactor(linter/plugins): reimplement isSpaceBetween() isSpaceBetweenTokens() using tokens #16055
• Faster Rust implementation Linter plugins: Rustify token methods #16207

Code path analysis

Lowest priority, because probably rarely used APIs, and potentially difficult to implement.

• Augment the walker/visitor to support https://eslint.org/docs/latest/extend/code-path-analysis

Testing

• Rule tester Linter plugins: Rule tester #16018
• Use rule tester to test popular ESLint plugins, and ESLint built-in rules that Oxlint doesn't natively support

TS types

Weirdly, types seem to work fine in our test fixtures, but then don't work when Oxlint is consumed externally. 🤷

• Improve our TS type defs, so they work for plugins written in TS

Language server

• Support JS plugins in language server

Framework plugins

At present we don't support linting sections of multi-part files. It's tricky because raw transfer expect the source text to start at very start of the buffer. Supporting BOM (#12526) and supporting multi-section files are connected in this respect.

There are likely other features we'll need to implement to support linting other sections of single-file components (e.g. custom "processors").

First step is to research and scope out what's required.

Bug fixes + refactor

• Fix out-of-memory errors on Windows linter: Experimental jsPlugins not loading on windows #14375 (we need to replace our allocator - please leave this one to @overlookmotel)
• Refactor how plugins + rules are stored in configs on Rust side Linter plugins: Various changes #12437

[KieranP]

"3. Support framework plugins" 🎉🎉🎉 I have been using the linter for months now, works great on JS/TS, and have been eagerly waiting for Svelte support.

Out of curiosity, how do you think you will proceed with this? To my thinking, there are 2 ways this could be done:

1. Have OxLint support custom/plugin Rust parsers. OxLint would send the file contents to the parser, the parser would convert to TypeScript (along with a source map), OxLint would lint the TypeScript, then pass the lint results back to the parser. The parser would map the lint results back to the original file via the source map generated earlier, before passing the remapped results back to OxLint for output. OxLint -(Svelte)-> RustParser -(TS)-> OxLint -(TSLintResults)-> Parser -(RemappedLintResults)-> OxLint -> Stdout

2. Have OxLint support custom/plugin JS parsers. Basically the same as option 1, but perhaps is the easiest ecosystem friendly option, since a lot of frameworks like Svelte, Vue, etc already have JS based parsers they use for ESLint. So I imagine there would be far less changes than writing a parser in Rust. OxLint -(Svelte)-> JSParser -(TS)-> OxLint -(TSLintResults)-> JSParser -(RemappedLintResults)-> OxLint -> Stdout

I suppose both of these could be supported at the same time (some might use JS parsers until later when they can write a Rust based one). Would be interested to hear if there is a 3rd approach that is being considered.

[overlookmotel]

how do you think you will proceed with this?

Unclear as yet. Custom Rust parsers would be extremely difficult, but solution 2 is not so easy either. We currently have no way to get a JS AST back into Oxc's Rust side (which is why there's no oxc-codegen NPM package). There's also the perf impact of multiple round-trips in/out of JS to consider. This is going to require research and a lot of head-scratching!

[lachieh]

What about using Wasm components? If an interface for parsers (and/or rules) is defined with WIT, then it'd be possible to use the wasmtime crate to call into any Wasm component that satisfies the interface. That would mean that it's possible to create a parser using any language that supports compiling to Wasm components which—as of writing this—includes JS through componentize-js. Hand-waving on a lot of details here, and ignoring some of the overhead costs but it does enable a polyglot+modular approach.

[gabrielcsapo]

is someone taking over Support JS plugins in language server? I might have a free cycle to work on this if no one has already started

[camc314]

is someone taking over Support JS plugins in language server? I might have a free cycle to work on this if no one has already started

Thanks for your interest, however we need to complete #15119 first before this can be worked on.