5 ms·

> Running NPM Update ranges from doing not much at all, to breaking my entire system making deleting all of node_modules the only realistic fix. Why not just p

> Running NPM Update ranges from doing not much at all, to breaking my entire system making deleting all of node_modules the only realistic fix. Why not just pin your dependencies to specific versions, ie - “somepackage”: “4.2.9” ?

megaman22 8y ago
I'm borderline infuriated that this isn't the default way that npm works. Maybe if people didn't willnilly break things and followed semver, it'd be okay, but I waste too much time bisecting why some package that used to work is blowing up my build or failing in less obvious ways. But I'm a crusty almost-30 .Net developer used to Nuget.
- allover 8y ago
  npm does maintain a lockfile for you by default since npm 5, if that's what you mean. There really is no reason to be encountering surprise sub-dependency changes with npm.
  - megaman22 8y ago
    Happens all the time when package.json defaults to foo: "^1.2.3", and some bozo does breaking changes in 1.2.5.
    - danabramov 8y ago
      If you have a package lock, even caret in package.json won't automatically install it.
    - allover 8y ago
      > Happens all the time when package.json defaults to foo: "^1.2.3", and some bozo does breaking changes in 1.2.5. No it doesn't. Since npm 5, npm is lockfile-by-default, you don't get updates unless you ask for them. Whether one particular package correctly respects semver is irrelevant.
xab9 8y ago
Because that's not how it works. Subdependencies are still liable to slight shifting - of course there is the shrink-wrappish package-lock and npm ci, but they do some weird things I don't want to elaborate here. Npm is more fragile than it should be.
Tehnix 8y ago
Having to delete node_modules to “fix” it is indicative of a poor package manager. Although not entirely the same, it reminds me of cabal hell, in Haskell many years ago.
- always_good 8y ago
  I've had to do that with every package manager though.
  - theWheez 8y ago
    After working with pip and gradle I have never encountered that issue

megaman22 8y ago

I'm borderline infuriated that this isn't the default way that npm works. Maybe if people didn't willnilly break things and followed semver, it'd be okay, but I waste too much time bisecting why some package that used to work is blowing up my build or failing in less obvious ways. But I'm a crusty almost-30 .Net developer used to Nuget.

allover 8y ago
npm does maintain a lockfile for you by default since npm 5, if that's what you mean. There really is no reason to be encountering surprise sub-dependency changes with npm.
- megaman22 8y ago
  Happens all the time when package.json defaults to foo: "^1.2.3", and some bozo does breaking changes in 1.2.5.
  - danabramov 8y ago
    If you have a package lock, even caret in package.json won't automatically install it.
  - allover 8y ago
    > Happens all the time when package.json defaults to foo: "^1.2.3", and some bozo does breaking changes in 1.2.5. No it doesn't. Since npm 5, npm is lockfile-by-default, you don't get updates unless you ask for them. Whether one particular package correctly respects semver is irrelevant.

xab9 8y ago

Because that's not how it works. Subdependencies are still liable to slight shifting - of course there is the shrink-wrappish package-lock and npm ci, but they do some weird things I don't want to elaborate here. Npm is more fragile than it should be.

Tehnix 8y ago

Having to delete node_modules to “fix” it is indicative of a poor package manager. Although not entirely the same, it reminds me of cabal hell, in Haskell many years ago.

always_good 8y ago
I've had to do that with every package manager though.
- theWheez 8y ago
  After working with pip and gradle I have never encountered that issue