oxlint port

[nickjvandyke]

Just publicly tracking that I plan to investigate how this might look in oxlint. It's gaining steam and I'm a big fan of the VoidZero kit 👍

The concepts probably transfer well enough, but the implementation is quite complex and likely ESLint-specific.

I believe the work in oxc-project/oxc#9905 lets oxlint use the JS implementation of this plugin? But depending on difficulty and relative performance, it may still be worth porting.

[nickjvandyke]

The plugin seems a lot stabler these days, so it may be about time to start on this!

I am curious to formalize the plugin's graph implementation first, but not a hard requirement.

I suppose first I should try this plugin in oxlint (via oxc-project/oxc#9905). Hopefully it works. If not, hopefully it's possible to refactor this plugin to only use supported APIs. Presumably much greater ROI than skipping straight to porting.

[nickjvandyke]

Confirmed it works with oxlint's compatibility layer 🙂

❯ yarn oxlint

  ⚠ react-you-might-not-need-an-effect(no-derived-state): Avoid storing derived state. Compute "cogs" directly d
uring render, optionally with `useMemo` if it's expensive.
    ╭─[src/Inputs.jsx:62:5]
 61 │   useEffect(() => {
 62 │     setCogs(chainrings);
    ·     ───────────────────
 63 │   }, [chainrings]);
    ╰────

Found 1 warning and 0 errors.
Finished in 523ms on 11 files with 102 rules using 8 threads.

[kurtextrem]

We're also using it via oxlint. Alex from the VoidZero team also mentioned on X they think js plugins are the way to go and they will further improve the performance of those. So personally I think a port to rust is not needed 😀

[nickjvandyke]

That's great to hear @kurtextrem, thanks for the info!

In that case, for now I'll try to refine our Oxlint setup docs. I see they don't support recommended ESLint configs, but we could spread the plugin's recommended config in oxlint.config.ts. I tried that and got a couple type errors, but I presume it's possible. Just need to refine the exported plugin's TS type to satisfy Oxlint's defineConfig.

In the meantime, if anyone experiences performance issues with this plugin, please let me know here! I have focused on functionality up to this point, but I think there's room to focus on performance soon, if warranted.

[pbomb]

FYI, I'm in the process of migrating our company's TS monorepo from eslint to oxlint and use this plugin. I'm seeing some incorrect behavior with the no-empty-effect rule that we aren't seeing when using through eslint.

The rule triggers only in oxlint for an effect like this:

  useEffect(() => {
    document.getElementById('main-content').scrollIntoView();
  }, []);

Changing it to this satisfies the rule:

  useEffect(() => {
    const content = document.getElementById('main-content');
    content.scrollIntoView();
  }, []);

I also see these errors in oxlint for more simple cases like this:

  useEffect(() => {
    analytics.track();
  }, []);

Let me know if you want me to file this in a separate issue.

[nickjvandyke]

Thanks @pbomb! Fixed (via removal - see issue and PR for reasoning) in v0.10.0 🙂