Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Assess the benefits of- and consider raising minimum Node.js version #63

Open
wojtekmaj opened this issue May 4, 2024 · 2 comments
Open

Comments

@wojtekmaj
Copy link

Most modern tools like Vite, ESLint are currently targeting Node.js 18.x and 20.x. I find nolyfill supporting older versions of Node kind of ironic, but at the same time I lack any information on what potential improvements (and new nolyfills?) are we missing out on by supporting Node.js 12-17.

@SukkaW
Copy link
Owner

SukkaW commented May 4, 2024

I have been considering this for a long time now. I originally choose 12.22, because it is the minimum Node.js version that has full ES2018 and partial ES2019 supports.

Raising the minimum required Node.js version might not bring significant benefits for the nolyfill. The nolyfill does contain a small set of polyfills for ES2018+ features that are not available on Node.js 12 (Promise.allSettled, Promise.withResolvers, etc.), raising the minimum Nose.js version will only get rid of these polyfills.

And the nolyfill CLI has made a very big mistake. When writing overrides to the package.json, I accidentally uses @latest (e.g. @nolyfill/hasown@latest). I use latest because I don't want downstream to have several versions of @nolyfill/shared. But now if I introduce a breaking change, even if I follow the semver, it could still break many existing projects. The solution for this would be using a new npm tag when publishing packages, just like the way how yarn 2 and yarn 3 are published to the npm registry.

@wojtekmaj
Copy link
Author

I agree that's a mistake, but not one you can't recover from IMO.

Minimize the damage and change @latest to @1. The sooner, the smaller the issue is going to be.

Add some code to swap the former with the latter so subsequent runs of the CLI would fix the ranges.

Whoever already used nolyfill CLI, will have a lockfile where @latest resolved to v1 anyway. This won't change until:

  • soon-to-be-fixed v1 CLI is run and changes range to @v1
  • v2 CLI is run and changes range to @v2

This would limit the users affected with @latest to the users who don't use the lockfile, in which case, they would receive what they deserve TBH 🤣

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants