search

jsx-eslint / eslint-plugin-jsx-a11y

Static AST checker for a11y rules on JSX elements.
MIT License
3.41k stars 635 forks source link

CI is failing on old Node versions #914

Closed JoshuaKGoldberg closed 1 year ago

JoshuaKGoldberg commented 1 year ago

Node versions 11 and below are failing in GitHub Actions. They're also past EOL. Can they be removed?

Example: #913 -> https://github.com/jsx-eslint/eslint-plugin-jsx-a11y/actions/runs/3875057562/jobs/6607126082.

ljharb commented 1 year ago

The solution is to fix it, not drop them - EOL status is irrelevant, always.

ljharb commented 1 year ago

This is due to https://github.com/mattcg/language-tags/issues/15#issuecomment-1376114476; I'll update your PR to pin it.

JoshuaKGoldberg commented 1 year ago

Also from https://github.com/jsx-eslint/eslint-plugin-jsx-a11y/pull/915#pullrequestreview-1240993265:

there's no reason to do it

Is there another place this has been discussed? And/or other discussions I should look at? To my knowledge, this is the only ESLint plugin that tests so aggressively into old versions - and I don't see any reason to add support for years-out-of-usage Node versions.

ljharb commented 1 year ago

eslint-plugin-react and eslint-plugin-import both do it - eslint-plugin-import tests down to eslint v2.

CI noise isn't an actual problem, and newer APIs can be used as long as there's reasonable fallback behavior.

Transpiler output size is irrelevant because this is a dev tool, and disk space is infinite and free.

JoshuaKGoldberg commented 1 year ago

eslint-plugin-react and eslint-plugin-import both do it - eslint-plugin-import tests down to eslint v2.

I should have asked: places you personally don't have significant involvement? I don't mean this as a personal jab - just trying to see if there's real demand in the community for old support.

Another point against old version support being useful is that most libraries don't actively test for deprecated Node support. Even if ESLint and all its plugins happen to work, other dev tooling is very likely to not. So, even if eslint-plugin-*s are the only ones supporting old versions, that doesn't mean folks can practically use them.

newer APIs can be used as long as there's reasonable fallback behavior.

...at the cost of using fallbacks/polyfills in code, no? Which makes development harder.

CI noise isn't an actual problem

It is for me! It's inconvenient having so many to scroll through. And anecodtally speaking, if there's any duplication in CI runs (e.g. having a dozen Node versions instead of 3-4), it's especially confusing for newer developers.

disk space is infinite and free

Heh, this isn't going to be my most convincing argument set, but I don't quite agree:

The way I see it, this project is going out of its way to support old Node versions. If it does an eventual next major version, I don't see any strong justification to keep those old versions.

ljharb commented 1 year ago

I agree that there are few major packages at this point that follow my stance, but that doesn't make it wrong :-)

Development isn't significantly harder by using polyfills or fallbacks, and I'm always happy to add them into someone's PR if it's an issue.

I see what you mean about the multiple CI jobs, but usually i just "find in page" on the PR page for "failing", which jumps me directly to the one i need to look at.

A breaking change is going out of one's way, and it forces things like needing to backport security fixes to support downstream usage. The highest cost - including out of everything you've mentioned - to the developer community that I've seen over my entire career comes from package developers who have aggressively dropped node versions, thus incrementing the major, and thus creating ecosystem fragmentation.

Pick a major package that does frequent majors, and look at the download counts for it - how many people get left behind on old majors? Within a single major, virtually everyone is always concentrated on the latest release for it, which is great for security and reliability - but with multiple depended-upon major lines, a bunch of human beings get left out in the cold. It's simply user-hostile to do unnecessary breaking changes.

JoshuaKGoldberg commented 1 year ago

Makes sense. This & other packages then have two competing concerns:

How do we find that balance? For example: Node 6 hit end of life >4.5 years ago, and end of security support >3.5 years ago. How likely is it that bumping to Node 8 and higher in the next v7 -whenever it would happen- would inconvenience anybody who is actively bumping package versions?

I'd also posit that it can be good to pressure folks to get off versions of Node that are past security support. Node versions <14 are inherently insecure systems to use given that they no longer receive security support.

Rough proposal: for eslint-plugin-jsx-a11y, eslint-plugin-react, and eslint-plugin-import, can there be a standard for how far back you want to support old Node versions? Say, 6 months past end of security support? Then, whenever the's going to be a major version change anyway, can the packages dropping old Node support be part of that?

ljharb commented 1 year ago

I very much disagree that it is the job of package authors to pressure folks to upgrade node, and I also disagree that it's good - it's actually quite bad. Precisely zero people are stuck on an old node version merely out of laziness, they're stuck there for other reasons that package authors can't change - by making life harder for them, we're making them LESS secure, and we aren't helping them upgrade, we're actually making it much harder.

The standard is, and will be, "we support the same things as close to forever as possible, and we'll only to a semver-major when strictly necessary, and only then will we re-evaluate what's worth supporting".

JoshuaKGoldberg commented 1 year ago

That's a good point. Retracted on that front 🙂

ljharb commented 1 year ago

Don't get me wrong - if at some point in the future, any of these 3 eslint plugins has a semver-major, it will give me great joy to delete all of the workarounds and branches and test cases for the things being dropped (like the old TS eslint parser, the old babel parser, or older versions of eslint), and my life will be MUCH easier as a result.

However, my personal convenience is eternally less important and less of a priority than the convenience of every single individual user of my software, and I refuse to neglect that burden.

JoshuaKGoldberg commented 1 year ago

Very noble 😄 and I can definitely see where you're coming from.

Other than the "job of package authors to pressure folks to upgrade node" point, I still stand by my request, understanding your counterpoints. I'm requesting we put more weight of the personal convenience -or, as I'd put it, time efficiency & ability to be more productive- of the maintainer(s). If working on a project is some percent slower & more aggravating for version support a small percentage of users need, is that really worth it for users?

For example, I try to avoid working in repos that combine odd requirements or restrictions such as old Node versions (along with other quirky decisions in these repos), because I know I'm both less efficient & have less tolerance for debugging as a result of those quirks. I know of other folks who do the same.

If this thread is getting long in the tooth and we've just entrenched our positions, I can stop bothering you with this. But it really feels off to me to go through such effort to keep such ancient support knowing it's slowing down project development.

ljharb commented 1 year ago

I think that might be the crux - it's not slowing down project development for the primary maintainer. It certainly might be mildly inhibiting contributors, and I can't speak to that, but it doesn't make sense to me to make technical and product decisions based on reducing potential barriers for contribution (not that reducing barriers wouldn't be a good thing, of course!)