A more agnosticism plugin name eslint-plugin-jsx?

[JounQin]

Hi @Rel1cx .

I believe jsx is not only for react and this amazing ESLint plugin can benefit other jsx friendly frameworks like preact, solid, vue, etc.

And I just got the eslint-plugin-jsx npm package maintainer permission from @jkroso , I'd like to propose to change the current plugin more agnosticism.

How do you think?

Don't mind if you don't agree with me.

Best wishes.

[SukkaW]

I believe jsx is not only for react and this amazing ESLint plugin can benefit other jsx friendly frameworks like preact, solid, vue, etc.

JSX in Solid and Million.js act very differently than the one in React. We might focus more on the JSX usage in React and Preact for now, but feel free to contribute universal JSX linting/formatting rules!

[JounQin]

I understand the jsx specs could be different between different frameworks. And they could be handled specifically like https://github.com/eslint-react/eslint-react?tab=readme-ov-file#react

Or a setting like framework: 'react' | 'preact' | 'solid' | 'vue' could be configured.

[SukkaW]

I understand the jsx specs could be different between different frameworks. And they could be handled specifically like https://github.com/eslint-react/eslint-react?tab=readme-ov-file#react

Or a setting like framework: 'react' | 'preact' | 'solid' | 'vue' could be configured.

We can achieve that with ESLint presets (jsx/react-recommended of sort).

[JounQin]

We can achieve that with ESLint presets (jsx/react-recommended of sort).

A same rule could run differently between different frameworks, for example hooks for react and composition API for vue both use use prefix but hooks for react require more limitations. What means some rules need to be framework related. Of course this example is only for demo purpose.

[Rel1cx]

It's a good point, "JSX is not only for React". I've expressed similar views before, but after considering and implementing the current series of React's JSX rules, I prefer it's better not to develop all framework's JSX rules in this one repo. The reasons are as follows:

If we divide JSX rules into stylistic and correctness, for stylistic rules, indeed the vast majority are framework-independent and universal. And the best way to contribute to these rules now and in the future is to contribute to @stylistic/eslint-plugin-jsx.

As for correctness rules, an undeniable fact is that they are strongly related to the behavior of the framework. Different frameworks (or even the same framework, e.g. the same React but rendering not to DOM but to a non-DOM medium by a Custom React Renderer).
At this time, the behavior of the framework and the "best practices" will be different (I can give you a simple example, for example, if we're considering whether passing some unstable props to a JSX element causes unnecessary re-reconciliation, this may not be a problem if the element is a normal DOM element in React, but it might not be the same in other frameworks or renderers, and vice versa), and it will make the behavior of the rules more unpredictable and even cause conflicts.

Adding "a setting like framework: 'react' | 'preact' | 'solid' | 'vue' could be configured". This will increase the complexity in all JSX-related modules and rules development processes, and in other processes, such as:

Increase confusion in all JSX-related rules's issue reporting (need to first determine which framework the behavior occurred under).
Increase difficulty in subsequent version updates and backward compatibility, and may be more prone to breaking changes.
...

So considering the above, I believe that continuously developing and publishing @eslint-react/jsx (The AST Utility Module for Static Analysis of JSX in ESLint, it's truly universal) to benefit other JSX friendly frameworks, rather than including all differences of frameworks that use JSX in this project, is a better choice.

[Rel1cx]

Where JSX fits into the ecosystem of front-end languages and frameworks

JS in Vue
TS in Vue
TSX in Vue

JS in Solid
TS in Solid
TSX in Solid

...

In essence, JSX is just a syntax extension, how to lint TSX here is the same as TS, JS here, it's all up to the frameworks, making an eslint-plugin-jsx that doesn't just take care of the correctness of JSX itself, but also has to be configured (or prefixed) to support the behaviour of all the specific frameworks that have used JSX in the past, are using JSX now, and will be in the future is equivalent to making a @typescript-eslint/eslint-plugin but not only for the correctness of ts itself but also configured (or prefixed) to support the behaviour of all the frameworks that use ts, React, Preact, Solid, Vue, etc.