search

SukkaW / nolyfill

Speed up your package installation process, reduce your disk usage, and extend the lifespan of your precious SSD.
MIT License
1.07k stars 15 forks source link

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

Open wojtekmaj opened 4 months ago

wojtekmaj commented 4 months ago

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 commented 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.

wojtekmaj commented 4 months ago

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:

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 🤣