search

SukkaW / nolyfill

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

Why `@latest`? #73

Closed fregante closed 4 months ago

fregante commented 5 months ago

As pointed out in a recent ljh debacle, dependencies should not use branch references, but explicit versions.

Any particular reason why this points to latest?

Also, why don't all these packages look just like module.exports = Array.prototype.findLast?

SukkaW commented 5 months ago

@latest was a serious mistake of mine: https://github.com/SukkaW/nolyfill/issues/63#issuecomment-2094345236

And the nolyfill CLI has made a very big mistake. When writing overrides to the package.json, I accidentally use @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.

So in case any breaking change is going to be made, I will publish the new packages under a different tag (to make sure previous @latest usage won't be broken).

SukkaW commented 5 months ago

Also, why don't all these packages look just like module.exports = Array.prototype.findLast?

ljharb creates his own polyfill behavior spec (called es-shim). And his projects are heavily based on his polyfill behavior. So I have to make the replacements behave exactly the same to prevent breaking.