Open wojtekmaj opened 4 months ago
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.
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:
@v1
@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 🤣
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.