3 ms·

For what it's worth; `eslint-plugin-react` has been around for a long time and seems to support running in very old versions of Node.JS (back to v4[1] apparentl

For what it's worth; `eslint-plugin-react` has been around for a long time and seems to support running in very old versions of Node.JS (back to v4[1] apparently! tho I can't find anything documenting that for sure.) I was surprised to learn that Object.values is only supported in Node >v7, Object.fronEntries was added in v12, etc. So for this project maybe the polyfills are needed. [1] https://github.com/jsx-eslint/eslint-plugin-react/pull/1038 https://github.com/jsx-eslint/eslint-plugin-react/pull/1038

mhagemeister 3y ago
Yeah, engines are a moving target. I'm all for backwards compatibility, but I'm worried about promoting old node versions with known unpatched security issues. Given that eslint itself only supports node >= 12.22.0 it seems like it's time to get rid of the polyfills. I wish we as in the industry would find a better solution to adapt to this. It's a bit unfortunate that the polyfills as part of the library code itself, which makes it difficult to get rid of them once they're not needed anymore.
gigel82 3y ago
Genuinely curious, are there people out there using newer versions of this package with old / unsupported versions of Node (in production)?
- silverwind 3y ago
  Not really. Adoption of new Node versions is quite quick, given their short support periods. https://nodejs.org/metrics/summaries/version.png https://nodejs.org/metrics/summaries/version.png
- phire 3y ago
  It probably happens, but not really on purpose. If the package.lock file gets deleted or someone runs a global npm-update then npm will update any packages while respecting semantic versioning. It's possible an organisation forgot to include the package.lock file in their deployment image and they get updated npm packages every time they redeploy. It's also possible a developer making minor changes to a legacy system triggers packages to be updated, perhaps without even noticing.
phire 3y ago
There are two separate questions: "Should libraries still be polyfilling to support ancient runtimes?" and "How should that polyfilling be implemented?" Even if a library wants to maintain backwards compatibility, we can still argue this method of polyfilling (especially the phony polyfills) is damaging to the wider javascript ecosystem. In an ideal world, the cost of polyfills for developers who don't need them should be zero. For developers using bundlers, the bundler is expected to implement any required polyfills for the developer's targeted runtimes, and having the library ship with it's own polyfills is counterproductive at best. However, I suspect these libraries wish to maintain compatibility for developers not using bundlers. Maybe npm should be upgraded to support multiple variants of packages? That way these libraries could ship both polyfilled and non-polyfilled versions of their packages in parallel.

mhagemeister 3y ago

Yeah, engines are a moving target. I'm all for backwards compatibility, but I'm worried about promoting old node versions with known unpatched security issues. Given that eslint itself only supports node >= 12.22.0 it seems like it's time to get rid of the polyfills. I wish we as in the industry would find a better solution to adapt to this. It's a bit unfortunate that the polyfills as part of the library code itself, which makes it difficult to get rid of them once they're not needed anymore.

gigel82 3y ago

Genuinely curious, are there people out there using newer versions of this package with old / unsupported versions of Node (in production)?

silverwind 3y ago
Not really. Adoption of new Node versions is quite quick, given their short support periods. https://nodejs.org/metrics/summaries/version.png https://nodejs.org/metrics/summaries/version.png
phire 3y ago
It probably happens, but not really on purpose. If the package.lock file gets deleted or someone runs a global npm-update then npm will update any packages while respecting semantic versioning. It's possible an organisation forgot to include the package.lock file in their deployment image and they get updated npm packages every time they redeploy. It's also possible a developer making minor changes to a legacy system triggers packages to be updated, perhaps without even noticing.

phire 3y ago

There are two separate questions: "Should libraries still be polyfilling to support ancient runtimes?" and "How should that polyfilling be implemented?" Even if a library wants to maintain backwards compatibility, we can still argue this method of polyfilling (especially the phony polyfills) is damaging to the wider javascript ecosystem. In an ideal world, the cost of polyfills for developers who don't need them should be zero. For developers using bundlers, the bundler is expected to implement any required polyfills for the developer's targeted runtimes, and having the library ship with it's own polyfills is counterproductive at best. However, I suspect these libraries wish to maintain compatibility for developers not using bundlers. Maybe npm should be upgraded to support multiple variants of packages? That way these libraries could ship both polyfilled and non-polyfilled versions of their packages in parallel.