[@types/eslint-plugin-jsx-a11y] ESLint dependency #74583
Replies: 3 comments 1 reply
-
|
Thanks for the discussion about "eslint-plugin-jsx-a11y", some useful links for everyone: Pinging the DT module owners: @eagerestwolf, @ljharb. |
Beta Was this translation helpful? Give feedback.
-
|
I’m rather torn on this one. While that is correct, there are quite a few users that don’t plan to/won’t upgrade to ESLint 9 due to the breaking API changes. While those users can’t use |
Beta Was this translation helpful? Give feedback.
-
|
As I understand it, that's handled by NPM's normal support for installing more than one version of a package. For example, with @types/eslint-plugin-jsx-a11y's current
So users of older ESLint versions get stuck with installing two versions of ESLint, which is unfortunate, but things work. |
Beta Was this translation helpful? Give feedback.
-
|
You are correct in that regard, and everything would work; but I’m concerned about the double dependency situation. Don’t get me wrong, we already are in a double dependency situation, but I am much more comfortable having a user install a types package that isn’t too far out of date and only takes a few kilobytes versus having two versions of ESLint installed taking many megabytes. I will admit that in the modern era of multiple terabyte flash storage options, it seems silly to care about a few megabytes; and the issue can be negated entirely using something like pnpm where packages are only downloaded once and linked to a central repository. However, this particular plugin is used predominantly with React (although Solid, Vue, and others can make use of it if they use JSX), and some React codebases can be extremely large, not to mention a lot of large corporations utilize React and may not have their development machines equipped with a lot of storage. This is the one thing that makes me hesitant. Perhaps, we can reach a compromise here. What if we do make the suggested change, but bump the major version of the package so that way it isn’t an automatic update, and users will need to manually opt in (i.e. Unfortunately, I am not equipped to do code editing at this point in time due to my work situation (I am an OTR truck driver and don’t have a laptop on my truck at the moment), but it sounds as though you have already made the required changes. If you would like to submit a PR with the changes and bump the major version, I would be happy to give my blessing for it to be merged. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I'm looking at the dependency handling for eslint-plugin-jsx-a11y (and, I suppose, other eslint-plugin-... types):
These depend on ESLint types, so they need a way of accessing ESLint types.
ESLint started including its own types in (I think) version 9.10.0. (See #70735).
Therefore, @types/eslint is now frozen at 9.6.1.
@types/eslint-plugin-jsx-a11y et al. don't want to depend on @types/eslint; that's out of date, so using it may cause type errors. (See #73831.)
But the solution of depending directly on
"eslint": "^9"also seems wrong, for two reasons: anything in >= 9.0.0 < 9.10.0 won't work, and, now that I've upgraded to ESLint 10, I'm stuck pulling in two different versions of ESLint just to satisfy plugins' typing.Would it work to instead depend on
"eslint": ">=9.10.0"? That has its own disadvantages (risking SemVer major breaking changes - although plugin config types seem stable enough), but it avoids installing multiple versions of ESLint, and any project that uses an ESLint plugin is presumably also picking a specific ESLint version itself.(For reference, within DefinitelyTyped, the types for eslint-plugin-jsx-a11y and eslint-plugin-mobx depend on
"eslint": "^9", while other ESLint plugins still depend in"@types/eslint": "*".)Beta Was this translation helpful? Give feedback.
All reactions