☂️ Oxlint Custom JavaScript Plugin Milestone 1

[Boshen]

The Oxlint Beta Annoucement briefly mentioned

One of the most commonly requested features for Oxlint is support for existing custom ESLint plugins. We have been busy working on the prerequisites for this feature, and to enable fast linter plugins written in JavaScript. We hope to have this feature available for the next major release, and more information to share about it in the near future.

Although it says "support for existing custom ESLint plugins", it does not mean it'll be 100% compatible, but I think it's achievable to make some tweaks to existing eslint rules and make them run on oxlint.

Stay tuned.

[Boshen]

From @overlookmotel :

First prototype of linter JS plugins is complete. #12350

Note: This prototype is a proof of concept rather than ready to release (see below).

Features

• Load JS plugins based on user-defined config files.
• Select JS rules to run based on config.
• Send ASTs from Rust to JS via raw transfer.
• Traverse ASTs on JS side using lazy deserialization.
• JS rules return errors/warnings to Rust, where they're merged with rest of errors.
• ESLint-compatible plugin API.

So far it's minimally-tested, but we've run it on VSCode repo and it appears to work.

Performance

We've only done a few quick benchmarks so far.

no-debugger rule (all other rules disabled), with rule implemented in Rust vs JS:

• 14 threads: Rust 135.9 ms vs JS 230.6 ms (70% slower)
• Single thread: Rust 622.4 ms vs JS 798.0 ms (30% slower)

30% perf cost for traversing every AST in full on JS side seems pretty good. We'll be able to improve multi-thread perf once we get JS plugins running in worker threads.

BUT…

Bad news: no-debugger rule plays to the strengths of lazy deserialization, because no files contain a DebuggerStatement, so no AST nodes get deserialized. AST is walked without creating any JS objects. A rule which visits all Identifiers and deserializes their names is 55% slower. More complex rules that touch more of the AST will have higher cost still.

Good news: Once default set of native rules are enabled, the cost of adding a JS rule as proportion of total time drops to only 15% (for the more expensive visitor).

We'll do more thorough benchmarks next week, but initial results suggest we're on the right track.

Main missing features / deficiencies

• Only bare bones API implemented. Only AST-walking. No APIs for accessing source code, ancestry, scopes, tokens, comments, control flow graph, selectors DSL etc.
• AST is not ESTree shape. It's more like Oxc's Rust types.
• Source ranges are UTF-8 bytes, not UTF-16 chars.
• All JS plugins run on main thread.

Next 2 weeks

• More benchmarking.
• Run JS plugins in worker threads.
• Clean up implementation, more tests, fix issues around config, low-hanging fruit perf optimizations.

Assuming we can get decent multi-thread perf, at that point we'll be able to confirm that we intend to go forwards with this approach. We should then be able to announce that JS plugins are coming and what they'll look like.

We'll then plan out work towards an alpha version we can release. Current guess of ETA for alpha: end Aug