3 ms·

tldr: A dependency wasn't pinned, the dependency changed, and stuff broke. Author thinks Javascript sucks. I will say this though: it is infuriating that packa

by yen223 3y ago

tldr: A dependency wasn't pinned, the dependency changed, and stuff broke. Author thinks Javascript sucks. I will say this though: it is infuriating that package managers (every single one I've used, not just NPM) don't default to pinning exact dependency versions, and instead let it "automatically" update minor versions.

pier25 3y ago
The package wasn't following semantic versioning. Only major versions should introduce breaking changes.
- yen223 3y ago
  The only change that isn't "breaking" is one that only adds functionality. Otherwise, it changes behavour, and has the potential to break your software. In practice, almost all changes should be major version bumps. Anyway that's besides the point. Let me control when version changes happen!
  - treflop 3y ago
    I used to maintain some open source libraries and absolutely no change we would release would break anything and definitely not over a minor version. We even did a major rewrite that completely changed the API and we broke nothing, but it did mean your project got a lot of deprecation errors. And our docs would mention both the old and new way so if you were searching the Internet for help, you wouldn't get confused when you saw wildly completely examples. It's all about craftmanship.
  - brazzy 3y ago
    >The only change that isn't "breaking" is one that only adds functionality. Ha! Think again. On of the more annoying problems I had to analyze was when a new PHP version added a function that already existed in my application (this was before namespaces). The runtime did not like that.
  - rezonant 3y ago
    Patch or major is always a judgement call. Making all changes a major jump is a bad idea, because it means that dependent packages are less likely to adopt important functionality or security fixes. NPM already gives you a way to control when version changes happen, it's called package-lock.json, and it's used for all NPM installs (both in development and when deploying). Just don't listen to the bootcampers on StackOverflow telling you to delete it whenever anything looks weird. If you delete package-lock.json, assume every dependency version has changed and regress accordingly. The same is true of all reasonable version-locking package managers.
- G3rn0ti 3y ago
  Unfortunately, this is purely convention and does not give a 100% guarantee of upgrading to latest minor versions not breaking your code.
G3rn0ti 3y ago
That’s why for building your JS bundle you’d use „npm ci“ instead of „npm install“ to avoid random upgrades of your packages. It uses your vc’ed „package-lock.json“ file containing your established dependency tree to build your JS bundle. However, if you need to integrate a new dependency it might require a later version of a package you already installed. NPM is clunky at times but most of the times it works quite well — despite all the micropackaging madness.
- rezonant 3y ago
  NPM uses your package-lock.json for normal installs as well. "npm ci" behaves nearly identical to npm install except for a few things, detailed here: https://docs.npmjs.com/cli/v8/commands/npm-ci https://docs.npmjs.com/cli/v8/commands/npm-ci Note that actually using package-lock.json to resolve dependency versions is not actually a difference between npm install and npm ci The real benefit is that npm ci will refuse to work if package.json and package-lock.json disagree, which protects against changing package.json without running NPM install during development.
rezonant 3y ago
This is not the default for NPM, Yarn, or PNPM. The "package-lock.json" is what does the pinning, and it's exact version. If you listen to very bad advice though, half of the Q&A answers on the Internet suggest all problems can be solved by deleting package-lock.json, to be fair.

by yen223 3y ago

pier25 3y ago

The package wasn't following semantic versioning. Only major versions should introduce breaking changes.

yen223 3y ago
The only change that isn't "breaking" is one that only adds functionality. Otherwise, it changes behavour, and has the potential to break your software. In practice, almost all changes should be major version bumps. Anyway that's besides the point. Let me control when version changes happen!
- treflop 3y ago
  I used to maintain some open source libraries and absolutely no change we would release would break anything and definitely not over a minor version. We even did a major rewrite that completely changed the API and we broke nothing, but it did mean your project got a lot of deprecation errors. And our docs would mention both the old and new way so if you were searching the Internet for help, you wouldn't get confused when you saw wildly completely examples. It's all about craftmanship.
- brazzy 3y ago
  >The only change that isn't "breaking" is one that only adds functionality. Ha! Think again. On of the more annoying problems I had to analyze was when a new PHP version added a function that already existed in my application (this was before namespaces). The runtime did not like that.
- rezonant 3y ago
  Patch or major is always a judgement call. Making all changes a major jump is a bad idea, because it means that dependent packages are less likely to adopt important functionality or security fixes. NPM already gives you a way to control when version changes happen, it's called package-lock.json, and it's used for all NPM installs (both in development and when deploying). Just don't listen to the bootcampers on StackOverflow telling you to delete it whenever anything looks weird. If you delete package-lock.json, assume every dependency version has changed and regress accordingly. The same is true of all reasonable version-locking package managers.
G3rn0ti 3y ago
Unfortunately, this is purely convention and does not give a 100% guarantee of upgrading to latest minor versions not breaking your code.

G3rn0ti 3y ago

That’s why for building your JS bundle you’d use „npm ci“ instead of „npm install“ to avoid random upgrades of your packages. It uses your vc’ed „package-lock.json“ file containing your established dependency tree to build your JS bundle. However, if you need to integrate a new dependency it might require a later version of a package you already installed. NPM is clunky at times but most of the times it works quite well — despite all the micropackaging madness.

rezonant 3y ago
NPM uses your package-lock.json for normal installs as well. "npm ci" behaves nearly identical to npm install except for a few things, detailed here: https://docs.npmjs.com/cli/v8/commands/npm-ci https://docs.npmjs.com/cli/v8/commands/npm-ci Note that actually using package-lock.json to resolve dependency versions is not actually a difference between npm install and npm ci The real benefit is that npm ci will refuse to work if package.json and package-lock.json disagree, which protects against changing package.json without running NPM install during development.

rezonant 3y ago

This is not the default for NPM, Yarn, or PNPM. The "package-lock.json" is what does the pinning, and it's exact version. If you listen to very bad advice though, half of the Q&A answers on the Internet suggest all problems can be solved by deleting package-lock.json, to be fair.