5 ms·

Wait, you're supposed to commit those? Genuinely curious. I always set up an ignore rule for them and use package.json's dependency list instead. My projects a

Wait, you're supposed to commit those? Genuinely curious. I always set up an ignore rule for them and use package.json's dependency list instead. My projects are all on the small side though; is the idea to commit the .lock file and avoid breakage through things like minor version updates of your first level dependencies? Wouldn't that carry a bigger security risk for large numbers of packages that then aren't receiving patch updates as readily?

JoBrad 7y ago
Yes https://docs.npmjs.com/files/package-lock.json https://docs.npmjs.com/files/package-lock.json
ossworkerrights 7y ago
Some people prefer to commit them (along with composer lock files for php). I always advise against it for this exact reason and because I want to make sure packages are correctly installed on the target system. Occasionally, deeply flawed versions are removed and it helps with catching it as well since you are forced to reinstall packages on a pull or build. Edit: a minor version update should not be backwards incompatible and break things. If it does, the package is poorly maintained imo.
- Aeolun 7y ago
  Not committing your lock file leaves you vulnerable to any of your dependencies publishing a new vulnerable version and directly updating to that. You can pick your poison.
  - ossworkerrights 7y ago
    There is also that. But one can reference the exact version and it becomes a non issue. In a properly secure environment it might be desirable. But as with everything there are pros and cons to each approach.
    - javagram 7y ago
      With NPM, this is not true. You can reference exact versions in every single entry in the package.json file and it doesn’t matter. Each one of those exact versioned libraries you referenced will itself likely have semantic version dependencies which may update themselves. Unless every single dependency you depend on also follows the policy of pinning to exact versions (and their dependencies do the same, and so on), you are still vulnerable (See left-pad incident, which was a sub-dependency of babel). The only way to avoid this is the old shrinkwrap or the new package-lock.json feature.
      - ossworkerrights 7y ago
        I stand corrected
tompic823 7y ago
Lock files are useful in production environments where you want to ensure the exact same package versions are being used that you tested with. A package.json file specifies package names and versions, but theres no guarantee your package registry will always serve the same content. The lock file records the hash of each package and uses it to verify package integrity on future installs. If any of the hashes don't match up, the `npm clean-install` command[0] will throw an error. [0] https://docs.npmjs.com/cli/ci.html https://docs.npmjs.com/cli/ci.html
- chrisweekly 7y ago
  Integrity checks are important, but an even more basic benefit obtains regarding version ranges. Typical package.json dependency entries specify _ranges_ of versions that will satisfy the dependency, rather than a single specific ("pinned") version. So it's by design, and fully to be expected, that over time, subsequent builds will yield different results as library authors publish newer versions which still satisfy the version ranges. Knowing when this has happened, and being able to diff the results in the dependency graph, is a key feature of lockfiles. A proper lockfile implementation (like yarn's) provides deterministic builds, so anyone building the project with the same lockfile gets precisely the same dependency graph. You get the benefits of version pinning without the downside.
crtlaltdel 7y ago
Before lockfiles I would pin version in my package.json file. Now, I still pin version in my package.json file ;)
- fiddlerwoaroof 7y ago
  package-lock is for pinning transitive dependencies, which package.json has no control over
coding123 7y ago
Commit your lock files, but never the node_modules folder.
- leipert 7y ago
  Well that depends. e.g. yarn has an auto clean feature and a feature to flatten the dependency tree. If you have a well groomed dependency tree, one might want to commit the node_modules folder: 1. Ultimately dependencies end up in your production environment, so folks might wanna review the diff of dependency updates. 2. No need to run yarn install. So if your build server has only access to your git repo, no need to get packages from a remote environment. 3. No need for yarn or npm on non-Frontend dev machines. It will just work with Node installed. 4. If npm or yarn ever cease to exist (or the registries), any commit should still work as intended.
  - korla 7y ago
    All of these (except 3) also get solved by moving dependencies to a hosted npm registry. Something which has been suitable for some projects I’ve worked on. And keeps ’git clone’-times down.
    - leipert 7y ago
      Well, not necessarily. Basically you create a new dependency and a piece of infrastructure _you_ need to maintain and that often still relies on yarn/npm upstream registries. So if that part of the infrastructure is down, you cannot work. A repo might be more error resilient, because if you check it out, you check it out.
  - strken 7y ago
    If you have native dependencies, committing node_modules will break cross-compatibility with different platforms.
    - coding123 7y ago
      That's exactly what we were hit with - a mix of Mac and PC developers and everything ploded (this was literally one of our first node projects about 5 years ago we didn't know to not commit node_modules)
stickfigure 7y ago
Without the package lock file, your build is not repeatable. In two years (or more likely, two weeks) someone new will check out your code, it will be broken out of the box, and the poor sod will have no idea why. More than likely they will blame you.
- mirekrusin 7y ago
  But package lock is ignored for all users of your npm. Only root package’s lock file has effect. This makes it useless in most cases. It’s even more useless if you think that production apps are built very often as tagged docker images = are reproducible by design.
  - allover 7y ago
    > But package lock is ignored for all users of your npm. Only root package’s lock file has effect. This makes it useless in most cases. But package-lock is intended to be used at the project level. i.e. lock all package versions in the current project or app. That isn't "useless in most cases", it solves specifically the case it is meant to solve. > It’s even more useless if you think that production apps are built very often as tagged docker images = are reproducible by design. But you're stuffed if you need to rebuild the docker image later, or for example, go back to an old commit/release, create a 'support' branch to retrofit a change and build a new image. You want repeatability all the way down.
- splix 7y ago
  May be I'm missing something, but why dependency resolution cannot be deterministic? If you always choose a version specified in the config, or a highest version if few different versions of the same dependency are defined through some of intermediaries, you'd always end with the same set. AFAIK it's the strategy in Gradle for JVM projects, and a similar deterministic strategy is used by Maven.
  - javagram 7y ago
    NPM resolution is not deterministic because package dependencies may be specified using SemVer, e.g. “~1.0.0” which may result in pulling 1.0.0, 1.0.1, 1.0.2, and so on - anything that matches 1.0.x specifier. The NPM ecosystem commonly uses these types of specifiers. Even if your own dependencies are all specified in “package.json” using exact versions, they almost certainly depend themselves on other versions (dependencies of dependencies, and so on) using the semver specifiers. That means whenever an author of that package publishes themselves, your resolved dependencies may change. The package-lock.json is simply a record of the exact dependency resolution graph based on the registry state that existed at the moment you generated it, so that you can reliably reproduce that graph a month or a year later. Otherwise it’s very common for NPM-based projects to have “NPM install” fail later on (or succeed, but create a bug or unit test failure) because some new version was added to the registry and created a compatibility issue or bug.
CGamesPlay 7y ago
> avoid breakage through things like minor version updates of your first level dependencies? No, a much more useful use case is avoid breakage from minor version updates in your 15th level dependencies. You might be cognizant of your semver best practices, but the team who publishes the string utility library included by the query builder included by your ORM might not be so careful.
- allover 7y ago
  > No, I think you mean "Yes, but also ..."
  - CGamesPlay 7y ago
    I don't really. If you only wanted to control your first-level dependencies, you would simply not use caret and tilde ranges in your package.json, no lockfile needed (except for cryptographic verification).
    - allover 7y ago
      > I don't really. If you only wanted to control your first-level dependencies They didn't say "only", they said "things like".

JoBrad 7y ago

Yes https://docs.npmjs.com/files/package-lock.json https://docs.npmjs.com/files/package-lock.json

ossworkerrights 7y ago

Some people prefer to commit them (along with composer lock files for php). I always advise against it for this exact reason and because I want to make sure packages are correctly installed on the target system. Occasionally, deeply flawed versions are removed and it helps with catching it as well since you are forced to reinstall packages on a pull or build. Edit: a minor version update should not be backwards incompatible and break things. If it does, the package is poorly maintained imo.

Aeolun 7y ago
Not committing your lock file leaves you vulnerable to any of your dependencies publishing a new vulnerable version and directly updating to that. You can pick your poison.
- ossworkerrights 7y ago
  There is also that. But one can reference the exact version and it becomes a non issue. In a properly secure environment it might be desirable. But as with everything there are pros and cons to each approach.
  - javagram 7y ago
    With NPM, this is not true. You can reference exact versions in every single entry in the package.json file and it doesn’t matter. Each one of those exact versioned libraries you referenced will itself likely have semantic version dependencies which may update themselves. Unless every single dependency you depend on also follows the policy of pinning to exact versions (and their dependencies do the same, and so on), you are still vulnerable (See left-pad incident, which was a sub-dependency of babel). The only way to avoid this is the old shrinkwrap or the new package-lock.json feature.
    - ossworkerrights 7y ago
      I stand corrected

tompic823 7y ago

Lock files are useful in production environments where you want to ensure the exact same package versions are being used that you tested with. A package.json file specifies package names and versions, but theres no guarantee your package registry will always serve the same content. The lock file records the hash of each package and uses it to verify package integrity on future installs. If any of the hashes don't match up, the `npm clean-install` command[0] will throw an error. [0] https://docs.npmjs.com/cli/ci.html https://docs.npmjs.com/cli/ci.html

chrisweekly 7y ago
Integrity checks are important, but an even more basic benefit obtains regarding version ranges. Typical package.json dependency entries specify _ranges_ of versions that will satisfy the dependency, rather than a single specific ("pinned") version. So it's by design, and fully to be expected, that over time, subsequent builds will yield different results as library authors publish newer versions which still satisfy the version ranges. Knowing when this has happened, and being able to diff the results in the dependency graph, is a key feature of lockfiles. A proper lockfile implementation (like yarn's) provides deterministic builds, so anyone building the project with the same lockfile gets precisely the same dependency graph. You get the benefits of version pinning without the downside.

crtlaltdel 7y ago

Before lockfiles I would pin version in my package.json file. Now, I still pin version in my package.json file ;)

fiddlerwoaroof 7y ago
package-lock is for pinning transitive dependencies, which package.json has no control over

coding123 7y ago

Commit your lock files, but never the node_modules folder.

leipert 7y ago
Well that depends. e.g. yarn has an auto clean feature and a feature to flatten the dependency tree. If you have a well groomed dependency tree, one might want to commit the node_modules folder: 1. Ultimately dependencies end up in your production environment, so folks might wanna review the diff of dependency updates. 2. No need to run yarn install. So if your build server has only access to your git repo, no need to get packages from a remote environment. 3. No need for yarn or npm on non-Frontend dev machines. It will just work with Node installed. 4. If npm or yarn ever cease to exist (or the registries), any commit should still work as intended.
- korla 7y ago
  All of these (except 3) also get solved by moving dependencies to a hosted npm registry. Something which has been suitable for some projects I’ve worked on. And keeps ’git clone’-times down.
  - leipert 7y ago
    Well, not necessarily. Basically you create a new dependency and a piece of infrastructure _you_ need to maintain and that often still relies on yarn/npm upstream registries. So if that part of the infrastructure is down, you cannot work. A repo might be more error resilient, because if you check it out, you check it out.
- strken 7y ago
  If you have native dependencies, committing node_modules will break cross-compatibility with different platforms.
  - coding123 7y ago
    That's exactly what we were hit with - a mix of Mac and PC developers and everything ploded (this was literally one of our first node projects about 5 years ago we didn't know to not commit node_modules)

stickfigure 7y ago

Without the package lock file, your build is not repeatable. In two years (or more likely, two weeks) someone new will check out your code, it will be broken out of the box, and the poor sod will have no idea why. More than likely they will blame you.

mirekrusin 7y ago
But package lock is ignored for all users of your npm. Only root package’s lock file has effect. This makes it useless in most cases. It’s even more useless if you think that production apps are built very often as tagged docker images = are reproducible by design.
- allover 7y ago
  > But package lock is ignored for all users of your npm. Only root package’s lock file has effect. This makes it useless in most cases. But package-lock is intended to be used at the project level. i.e. lock all package versions in the current project or app. That isn't "useless in most cases", it solves specifically the case it is meant to solve. > It’s even more useless if you think that production apps are built very often as tagged docker images = are reproducible by design. But you're stuffed if you need to rebuild the docker image later, or for example, go back to an old commit/release, create a 'support' branch to retrofit a change and build a new image. You want repeatability all the way down.
splix 7y ago
May be I'm missing something, but why dependency resolution cannot be deterministic? If you always choose a version specified in the config, or a highest version if few different versions of the same dependency are defined through some of intermediaries, you'd always end with the same set. AFAIK it's the strategy in Gradle for JVM projects, and a similar deterministic strategy is used by Maven.
- javagram 7y ago
  NPM resolution is not deterministic because package dependencies may be specified using SemVer, e.g. “~1.0.0” which may result in pulling 1.0.0, 1.0.1, 1.0.2, and so on - anything that matches 1.0.x specifier. The NPM ecosystem commonly uses these types of specifiers. Even if your own dependencies are all specified in “package.json” using exact versions, they almost certainly depend themselves on other versions (dependencies of dependencies, and so on) using the semver specifiers. That means whenever an author of that package publishes themselves, your resolved dependencies may change. The package-lock.json is simply a record of the exact dependency resolution graph based on the registry state that existed at the moment you generated it, so that you can reliably reproduce that graph a month or a year later. Otherwise it’s very common for NPM-based projects to have “NPM install” fail later on (or succeed, but create a bug or unit test failure) because some new version was added to the registry and created a compatibility issue or bug.

CGamesPlay 7y ago

> avoid breakage through things like minor version updates of your first level dependencies? No, a much more useful use case is avoid breakage from minor version updates in your 15th level dependencies. You might be cognizant of your semver best practices, but the team who publishes the string utility library included by the query builder included by your ORM might not be so careful.

allover 7y ago
> No, I think you mean "Yes, but also ..."
- CGamesPlay 7y ago
  I don't really. If you only wanted to control your first-level dependencies, you would simply not use caret and tilde ranges in your package.json, no lockfile needed (except for cryptographic verification).
  - allover 7y ago
    > I don't really. If you only wanted to control your first-level dependencies They didn't say "only", they said "things like".