4 ms·

NPM has had package locking since what feels like a million releases. I wish the Java community (which I'm actually also a part of) would stop rejecting everyt

NPM has had package locking since what feels like a million releases. I wish the Java community (which I'm actually also a part of) would stop rejecting everything that's not "the Java/enterprise way" and be humbled by exploring better alternatives, or alternatives with different tradeoffs for once.

catdog 5y ago
https://docs.gradle.org/current/userguide/dependency_locking.html https://docs.gradle.org/current/userguide/dependency_locking...
- egeozcan 5y ago
  I wasn't arguing that gradle didn't have such a mechanism but thanks :)
Larrikin 5y ago
I think his point was more of a cultural difference. My IDE actually lints non pinned dependencies as a potential source of errors, whereas in the JS world it seems very common to not pin.
- egeozcan 5y ago
  npm uses locks per default, and to disable that, you need to create a file called .npmrc at the root of the project and add package-lock=false to it. I don't think any popular project does that. It's also a common practice to use npm ci in all build scripts to never update packages even if they declared a version range in package.json, and package.lock not being able to satisfy package.json won't cause lock to get overwritten.
  - gkop 5y ago
    The fact that npm ci does what npm i should do (well, except for starting from scratch each time [0]), says it all. npm is a joke. [0] Yes, that's right. npm doesn't allow to to install incrementally respecting the lockfile. You can install incrementally with npm i and roll the dice, or install from scratch with npm ci to respect the lockfile. Basically the npm authors took the rm -rf node_modules/ workaround and productized it.
    - egeozcan 5y ago
      If you have a package.json and you run npm i it generates a package-lock.json from it. If you run npm i against that package.json and package-lock.json, the latter will never be updated, even if the package.json would be happy with newer versions. If you manually edit your package.json to have different ranges and run npm i and those ranges aren't compatible with your package-lock.json then the latter will be updated with version that are compatible with your package.json. Further runs of npm i will be as with 2 above. But of course you may think this behavior is a joke, I do not.
      - gkop 5y ago
        How can I incrementally install exactly what’s in the lockfile, raising an error if it’s incompatible with package.json? This is what I expect npm i to do, but as far as I can tell, npm simply doesn’t support.
        egeozcan 5y ago
        > raising an error if it’s incompatible with package.json How? Why? What's your use-case?
        gkop 5y ago
        Two essential use cases: 1) For local development, I’m seeking a command I can use after pulling, to safely and quickly install any needed dependencies that have been added by others. Currently I use npm ci but it’s absurdly overkill (and therefore very slow). 2) For CI itself. I cache node_modules/ across builds, which significantly speeds up my builds. Currently I npm i, and check if lockfile changed, and if it did, checkout lockfile and npm ci. I shouldn’t need to npm ci ever unless my node_modules/ became corrupt for some reason. Because npm ci ALWAYS blows away node_modules/, it’s not a reasonable piece of everyday functionality, it’s just a semantically ambiguous way to rm -rf node_modules/ && npm i -—respect-lockfile (made up flag I wish existed). The obvious explanation is that the npm developers couldn’t figure out how to reliably reconcile node_modules/ with the lockfile, so just gave up and shipped npm ci. Or if the rm -rf node_modules/ isn’t strictly necessary for npm ci, then give me npm ci —-skip-drop-node-modules, that would be equivalent and fine for my purposes.

catdog 5y ago

https://docs.gradle.org/current/userguide/dependency_locking.html https://docs.gradle.org/current/userguide/dependency_locking...

egeozcan 5y ago
I wasn't arguing that gradle didn't have such a mechanism but thanks :)

Larrikin 5y ago

I think his point was more of a cultural difference. My IDE actually lints non pinned dependencies as a potential source of errors, whereas in the JS world it seems very common to not pin.

egeozcan 5y ago
npm uses locks per default, and to disable that, you need to create a file called .npmrc at the root of the project and add package-lock=false to it. I don't think any popular project does that. It's also a common practice to use npm ci in all build scripts to never update packages even if they declared a version range in package.json, and package.lock not being able to satisfy package.json won't cause lock to get overwritten.
- gkop 5y ago
  The fact that npm ci does what npm i should do (well, except for starting from scratch each time [0]), says it all. npm is a joke. [0] Yes, that's right. npm doesn't allow to to install incrementally respecting the lockfile. You can install incrementally with npm i and roll the dice, or install from scratch with npm ci to respect the lockfile. Basically the npm authors took the rm -rf node_modules/ workaround and productized it.
  - egeozcan 5y ago
    If you have a package.json and you run npm i it generates a package-lock.json from it. If you run npm i against that package.json and package-lock.json, the latter will never be updated, even if the package.json would be happy with newer versions. If you manually edit your package.json to have different ranges and run npm i and those ranges aren't compatible with your package-lock.json then the latter will be updated with version that are compatible with your package.json. Further runs of npm i will be as with 2 above. But of course you may think this behavior is a joke, I do not.
    - gkop 5y ago
      How can I incrementally install exactly what’s in the lockfile, raising an error if it’s incompatible with package.json? This is what I expect npm i to do, but as far as I can tell, npm simply doesn’t support.
      - egeozcan 5y ago
        > raising an error if it’s incompatible with package.json How? Why? What's your use-case?
        gkop 5y ago
        Two essential use cases: 1) For local development, I’m seeking a command I can use after pulling, to safely and quickly install any needed dependencies that have been added by others. Currently I use npm ci but it’s absurdly overkill (and therefore very slow). 2) For CI itself. I cache node_modules/ across builds, which significantly speeds up my builds. Currently I npm i, and check if lockfile changed, and if it did, checkout lockfile and npm ci. I shouldn’t need to npm ci ever unless my node_modules/ became corrupt for some reason. Because npm ci ALWAYS blows away node_modules/, it’s not a reasonable piece of everyday functionality, it’s just a semantically ambiguous way to rm -rf node_modules/ && npm i -—respect-lockfile (made up flag I wish existed). The obvious explanation is that the npm developers couldn’t figure out how to reliably reconcile node_modules/ with the lockfile, so just gave up and shipped npm ci. Or if the rm -rf node_modules/ isn’t strictly necessary for npm ci, then give me npm ci —-skip-drop-node-modules, that would be equivalent and fine for my purposes.