Bug: eslint-plugin-react-hooks@6.0.0 suddenly installs the entire babel toolchain

[AviVahl]

After #32416 was merged and released as eslint-plugin-react-hooks@6.0.0, my react project suddenly got the entire babel toolchain, even though I do not use babel, or react-compiler at all.

My dependency count jumped by 37 new dependencies. I call this less than ideal, considering I do not need the react-compiler related functionality.

Having the two plugins as separate makes sense to me, as the compiler is optional.

I wonder, did you consider this when merging the two packages? Should I just fork eslint-plugin-react-hooks, as I only use react-hooks/rules-of-hooks and react-hooks/exhaustive-deps?

Thanks in advance.

Ref: wixplosives/sample-monorepo@e79349b

[poteto]

The compiler is optional now, but when it becomes stable we will be strongly recommending everyone use the compiler. Future React features will be built together with the compiler in mind and may not work without it.

6.0.0 was released by accident, 6.0.0-rc.1 is the one we are recommending folks use if they want to try out the compiler's eslint. You can revert that commit back to 5.2.0. However, note that when the compiler goes stable, we will be releasing eslint-plugin-react-hooks@6 with the compiler lint rule turned on by default.

If your project is not under active development, you can opt to stay on eslint-plugin-react-hooks@5.

[AviVahl]

Thank you for clarifying. I'll downgrade to 5.2.0 and consider my options once the react-compiler becomes "less" optional ("strongly recommending").

Might be a different discussion, but:

I really don't get how in a world where everyone is switching to a Rust/Go-based tooling, a major framework like React is going to force users to use the antiquated Babel toolchain and its JavaScript performance.

We've got esbuild, swc, oxc, and turbopack being the basis for many tools, both current and upcoming, such as vite, rspack, rolldown, next, etc. They might end up re-implementing the react-compiler in their language of choice, like some did for react-refresh, but that would cause some amount of fragmentation and overhead.