4 ms·

Thanks for your comment! - I don't use lockfiles - instead I use very very few dependencies, and I always target a specific version of each of them. I know thi

Thanks for your comment! - I don't use lockfiles - instead I use very very few dependencies, and I always target a specific version of each of them. I know this is not the same as a shrinkwrap, but I'm crazy enough to feel that package-lock.json adds visual bloat to my repo. - I am biased towards mon because it's probably less susceptible to changes over time than Ubuntu itself, and because it can be installed with a single command. But systemd definitely is a good option too if you're using Ubuntu!

riquito 7y ago
Lockfiles protect you from someone who would publish a malware that replaces an existing version (lockfiles have hashes alongside the versions)
- fpereiro 7y ago
  I believe that npm no longer allows for republishing existing versions. Wouldn't this restriction remove this vulnerability altogether?
  - try_again 7y ago
    It won't protect against a newer version of an established library introducing malicious behaviour.
    - bluehatbrit 7y ago
      This is correct, the few dependencies you would use would need to also target very specific versions to achieve the same. Lock files are used to lock dependency versions all the way down your dependency tree, not just your immediate dependencies.
      - fpereiro 7y ago
        Unfortunately this seems to be the case; lockfiles would be unnecessary only if all your dependencies (and their dependencies, recursively all the way down) reference explicit versions, the risk being that a new malicious version would be published. I'll research if there's a workaround. Thanks everyone for pointing out this issue.
        bluehatbrit 7y ago
        In my opinion a lock file really is the "work around", I don't see a huge issue in using them since it's given for free by npm and yarn with no additional overhead.
  - jessaustin 7y ago
    You can specify exact versions, but your deps might wildcard with "~" or "^" or they might specify a range of versions. Thus, a new dep of a dep might be installed the next time you update. I wonder whether one of the npm alternatives has a "--sane" mode that would always pick the oldest possible dep...
    - t0astbread 7y ago
      Why the oldest possible?
      - jessaustin 7y ago
        Thread hypothesis is that we want to avoid breakage due to automatic dependency updates. So, don't update dependencies automatically. Now sure, if you tell the tool to update a particular dep, it will force second- and higher-order deps to update to compatible versions. It will always use the oldest compatible version, so nothing will get broken in surprising fashion. This seems strange to people who've used mostly npm and node, but tools for other languages have this policy.
        t0astbread 7y ago
        I see. I've never heard of that before, thanks for sharing!
Merad 7y ago
The main problem with your approach is that you have full control over your dependencies but no control over their dependencies, unless you're inspecting every single package in your dependency graph to make sure that every one of them targets specific versions in its package.json. Realistically, using package-lock.json and npm ci is the only way to ensure that everyone on your team and your deployments are all working off of the same node_modules folder.
- deleted 7y ago
  [deleted]
marton78 7y ago
There's one problem with `npm ci`: it deletes the `node_modules` directory, thereby thwarting attempts at caching it between builds. As a workaround, we use `npm install` followed by `git diff --quiet package-lock.json`, which will abort the CI process if npm installing changed the lock file (i.e. if someone forgot to commit changes to it after adding a package).

riquito 7y ago

Lockfiles protect you from someone who would publish a malware that replaces an existing version (lockfiles have hashes alongside the versions)

fpereiro 7y ago
I believe that npm no longer allows for republishing existing versions. Wouldn't this restriction remove this vulnerability altogether?
- try_again 7y ago
  It won't protect against a newer version of an established library introducing malicious behaviour.
  - bluehatbrit 7y ago
    This is correct, the few dependencies you would use would need to also target very specific versions to achieve the same. Lock files are used to lock dependency versions all the way down your dependency tree, not just your immediate dependencies.
    - fpereiro 7y ago
      Unfortunately this seems to be the case; lockfiles would be unnecessary only if all your dependencies (and their dependencies, recursively all the way down) reference explicit versions, the risk being that a new malicious version would be published. I'll research if there's a workaround. Thanks everyone for pointing out this issue.
      - bluehatbrit 7y ago
        In my opinion a lock file really is the "work around", I don't see a huge issue in using them since it's given for free by npm and yarn with no additional overhead.
- jessaustin 7y ago
  You can specify exact versions, but your deps might wildcard with "~" or "^" or they might specify a range of versions. Thus, a new dep of a dep might be installed the next time you update. I wonder whether one of the npm alternatives has a "--sane" mode that would always pick the oldest possible dep...
  - t0astbread 7y ago
    Why the oldest possible?
    - jessaustin 7y ago
      Thread hypothesis is that we want to avoid breakage due to automatic dependency updates. So, don't update dependencies automatically. Now sure, if you tell the tool to update a particular dep, it will force second- and higher-order deps to update to compatible versions. It will always use the oldest compatible version, so nothing will get broken in surprising fashion. This seems strange to people who've used mostly npm and node, but tools for other languages have this policy.
      - t0astbread 7y ago
        I see. I've never heard of that before, thanks for sharing!

Merad 7y ago

The main problem with your approach is that you have full control over your dependencies but no control over their dependencies, unless you're inspecting every single package in your dependency graph to make sure that every one of them targets specific versions in its package.json. Realistically, using package-lock.json and npm ci is the only way to ensure that everyone on your team and your deployments are all working off of the same node_modules folder.

deleted 7y ago
[deleted]

marton78 7y ago

There's one problem with `npm ci`: it deletes the `node_modules` directory, thereby thwarting attempts at caching it between builds. As a workaround, we use `npm install` followed by `git diff --quiet package-lock.json`, which will abort the CI process if npm installing changed the lock file (i.e. if someone forgot to commit changes to it after adding a package).