Align Node version support with supported Node release

[TimvdLippe]

One of the dependencies of this packages (aria-query) would like to drop Node <12 support (A11yance/aria-query#158) since Node 10 is EOL (https://nodejs.org/en/about/releases/), but eslint-plugin-jsc-a11y depends on it and would have to drop Node <12 support as well. Could you consider aligning the supported Node releases of this package with the releases Node supports and thus drop support Node <12? That would allow aria-query to drop its Node support and significantly reduce its disk footprint in node_modules.

[ljharb]

That would be a very user-hostile approach. Node's platform support is irrelevant; we support "what people use", and capriciously dropping a platform creates churn and pain for users, for minimal benefit.

Disk space is infinite and free, and "disk footprint" isn't something that should be a high priority.

[nickserv]

It seems like we need this to properly support ES modules in Testing Library, can you please reconsider? I can try to help with PRs. testing-library/dom-testing-library#995

[ljharb]

@nickmccurdy In what way does this eslint plugin not work when using ES Modules?

For the record, there is NEVER a need to drop support for any node version just to support ESM.

[nickserv]

Sorry, I think I oversimplified my explanation and it wasn't entirely accurate.

DOM Testing Library relies on aria-query, which has broken ES modules because of its back compatibility support for Node 6 (though official support for it ended two years ago). Because of this issue and our framework wrapper packages like React Testing Library depending on DOM Testing Library, Testing Library packages cannot be used in ES module based tools like web-test-runner and esbuild. The solution (at least for aria-query, as we have other dependencies) would be to drop support for older dependencies in aria-query (A11yance/aria-query#180). However, this would mean that eslint-plugin-jsx-a11y would have to decide between not upgrading aria-query or upgrading it in a major release that drops the legacy Node support.

[ljharb]

In what way has supporting node 6 (we support older than that, I’m pretty sure) caused aria-query to break ES Modules? I helped design the feature in node, and there is zero reason that’s necessary.

[nickserv]

From what I understand in testing-library/dom-testing-library#995, the issue is related to either aria-query having legacy code that isn't compatible with newer Node releases, or it's just missing an ES module build. I'm not exactly sure if or what changes to aria-query are needed at this point, since I haven't been able to reproduce the issue myself and I'm making assumptions based on what users are saying about our package.

Sorry for the noise, I do appreciate your support. If I figure out that want an update to aria-query that would affect eslint-plugin-jsx-a11y, I'll try to crosspost an explanation or reproduction here.

[ljharb]

Aha - in that issue is buried the requirement for “build-less” ESM - that requirement is your problem, since that’s basically impossible in modern web dev. A bundler is simply required.

Having a package prepare an ESM build won’t solve this, because a) CJS bundles are way faster than native ESM, b) you still need a build process to build an import map, at a minimum, c) you still need a build process to enumerate which files you want served to the public, since serving all of node_modules would be a horrifically bad idea.

That said, any dep providing an ESM build can easily do so no matter how far back it supports engine versions, so i still don’t really understand the problem.