3 ms·

> that's just plain wrong there was at least one point in time where that was the recommended strategy

aalleavitch 9y ago
I'm not sure I could understanding the reasoning behind that. Does it have to do with dependency versions or the assumption npm might not be available or what?
- bpicolo 9y ago
  There were/are a few factors. NPM availability is definitely one - before caching, and without the overhead of running your own npm replica. It also didn't used to have things like lock files. Vendoring gives you a deterministic build and removes availability concerns. In that aspect, it's not the worst thing ever, mostly just leads to noisy diffs (and maybe c extension issues if your team works on a variety of OSs?) This is pretty much what the golang world does (though now there are some tools that do a better job).
- deleted 9y ago
  [deleted]
- yoz-y 9y ago
  Both actually. Even with yarn and lock files, npm servers can (and eventually will) pull a rug from under you. I have already been in a situation where a dependency version that I was locked to was simply removed from the official registry. The right solution is to have your own registry or backup the archives of dependencies that you are using. I think it is better to commit the archives rather than the whole node_modules as it does not produce a mess.
  - yeukhon 9y ago
    Yeah running a registry is the better option, although another solution is forking / committing the dependencies in a separate repository, and use branch + shallow clone to keep the download size small.
    - yoz-y 9y ago
      What I ended up doing at work is to have a docker image of a registry with package zips committed in the repo (with a small script to publish all packages in). That way I can rebuild a running registry in a few moments.
- deleted 9y ago
  [deleted]
- c_shu 9y ago
  like this one? https://evertpot.com/npm-revoke-breaks-the-build/ https://evertpot.com/npm-revoke-breaks-the-build/

I'm not sure I could understanding the reasoning behind that. Does it have to do with dependency versions or the assumption npm might not be available or what?

bpicolo 9y ago
There were/are a few factors. NPM availability is definitely one - before caching, and without the overhead of running your own npm replica. It also didn't used to have things like lock files. Vendoring gives you a deterministic build and removes availability concerns. In that aspect, it's not the worst thing ever, mostly just leads to noisy diffs (and maybe c extension issues if your team works on a variety of OSs?) This is pretty much what the golang world does (though now there are some tools that do a better job).
deleted 9y ago
[deleted]
yoz-y 9y ago
Both actually. Even with yarn and lock files, npm servers can (and eventually will) pull a rug from under you. I have already been in a situation where a dependency version that I was locked to was simply removed from the official registry. The right solution is to have your own registry or backup the archives of dependencies that you are using. I think it is better to commit the archives rather than the whole node_modules as it does not produce a mess.
- yeukhon 9y ago
  Yeah running a registry is the better option, although another solution is forking / committing the dependencies in a separate repository, and use branch + shallow clone to keep the download size small.
  - yoz-y 9y ago
    What I ended up doing at work is to have a docker image of a registry with package zips committed in the repo (with a small script to publish all packages in). That way I can rebuild a running registry in a few moments.
deleted 9y ago
[deleted]
c_shu 9y ago
like this one? https://evertpot.com/npm-revoke-breaks-the-build/ https://evertpot.com/npm-revoke-breaks-the-build/