4 ms·

> Once you check your node_modules in, there's no need to run an install step before you can get up and running on the codebase Is this really true for package

by cj 5y ago

> Once you check your node_modules in, there's no need to run an install step before you can get up and running on the codebase Is this really true for packages with pre/post install scripts?

Bellend 5y ago
No it's not. They are talking about their personal preference and it has nothing to do with real life employers.
- DaiPlusPlus 5y ago
  RTFA. It says, quite succinctly: > I currently work at Google on the Chrome DevTools team and we check our node_modules folder into source control
  - Bellend 5y ago
    Yeah I read that and I disagree because at google if I checked in my node_modules I would fail my commit.
    - DaiPlusPlus 5y ago
      The author says they work on Chrome. Chrome doesn't use Google's much-feared monorepo, so maybe they made it work for them? Can't you ping him internally (don't you guys still use WebEx? lol) to ask him to clarify, and find out how it works for their team?
  - dzhiurgis 5y ago
    tbf Google is so far ahead that it’s kinda not a real company. Aka you don’t have to adopt every best practice google does since you aren’t that big, mature, secure or rich.
    - DaiPlusPlus 5y ago
      Now we just need to convince all those startups burning cycles trying to get Kubernetes working instead of working on their actual product...
      - 3np 5y ago
        TFW you realize k8s isn't even used that widely inside Google.
        tentacleuno 5y ago
        What's your source on that? Would be interested to hear more. Aside: They seemed to like their Linux containers in 2014[0]. No idea if they're still using the same technique, or have maybe moved onto Kubernetes? [0]: https://www.theregister.com/2014/05/23/google_containerization_two_billion/ https://www.theregister.com/2014/05/23/google_containerizati...
        3np 5y ago
        Only anecdotes from several people working there at different divisions. I think I've seen it mentioned here at times as well. One of the lead devs - years of tenure - on one of the Android backend teams had barely heard of the name and wasn't sure what it was when I brought it up 2 years ago. Linux containers including Docker are absolutely widespread as I understand it, though.
    - tossaway9000 5y ago
      I second this, "google's problems are not your problems"
DaiPlusPlus 5y ago
Only if those packages' post-install scripts only mutate their own node_modules directory contents - and I can see this quickly falling-apart as soon as the team's dev-boxes becomes a heterogenous environment (e.g. someone using Ubuntu-on-WSL onboarding an all-M1 Mac team). Anyway, it's a given that I disagree with the article's specific point (i.e. to commit node_modules to source-control), however I am sympathetic to arguments about avoiding another left_pad incident, but there are better solutions to that then simplistically committing node_modules: 1. package-lock (though this is an incomplete solution: it helps to protects you from vague dependency version numbers (as it uses cryptographic hashes), but it doesn't store a copy of the npm package, and you need to make sure everyone is using the exact same npm/node tooling versions otherwise your package-lock file will be clobbered by different users checking-in wildly different `lockfileVersion` versions. 2. git LFS: every so often (once a month or so?) in a separate directory off-to-the-side, add a heavily compressed 7z LZMA archive of a snapshot of your node_modules directory (ideally in a known-good-state). This allows you to keep a repo-local copy of your important dependencies without it cluttering up your commits. While these would be monthly updates - and your actual package.json/package-lock.json dependencies may change daily or weekly - in the event of catastrophe it won't be too much work to track-down any missing dependencies or to revert the deps back to the last known-good LFS file. 3. Use tools like `offline-npm` and Verdaccio, which are NPM caching proxies. If this was 2019 and everyone was working in a central office then you'd run Verdaccio on a single box in your LAN and have everyone configure their NPM clients to route through that box, which then stores every package ever requested - you could presumably run a cron-job to ensure that package cache is backed-up somewhere safe, maybe even with git-LFS as discussed above.
- 3np 5y ago
  > the exact same npm/node tooling versions I've only ever had issues with differing major versions. That is, sharing lock-files between any node v14.x should work, but expect things to break if you go to v16.

by cj 5y ago

> Once you check your node_modules in, there's no need to run an install step before you can get up and running on the codebase Is this really true for packages with pre/post install scripts?

Bellend 5y ago

No it's not. They are talking about their personal preference and it has nothing to do with real life employers.

DaiPlusPlus 5y ago
RTFA. It says, quite succinctly: > I currently work at Google on the Chrome DevTools team and we check our node_modules folder into source control
- Bellend 5y ago
  Yeah I read that and I disagree because at google if I checked in my node_modules I would fail my commit.
  - DaiPlusPlus 5y ago
    The author says they work on Chrome. Chrome doesn't use Google's much-feared monorepo, so maybe they made it work for them? Can't you ping him internally (don't you guys still use WebEx? lol) to ask him to clarify, and find out how it works for their team?
- dzhiurgis 5y ago
  tbf Google is so far ahead that it’s kinda not a real company. Aka you don’t have to adopt every best practice google does since you aren’t that big, mature, secure or rich.
  - DaiPlusPlus 5y ago
    Now we just need to convince all those startups burning cycles trying to get Kubernetes working instead of working on their actual product...
    - 3np 5y ago
      TFW you realize k8s isn't even used that widely inside Google.
      - tentacleuno 5y ago
        What's your source on that? Would be interested to hear more. Aside: They seemed to like their Linux containers in 2014[0]. No idea if they're still using the same technique, or have maybe moved onto Kubernetes? [0]: https://www.theregister.com/2014/05/23/google_containerization_two_billion/ https://www.theregister.com/2014/05/23/google_containerizati...
        3np 5y ago
        Only anecdotes from several people working there at different divisions. I think I've seen it mentioned here at times as well. One of the lead devs - years of tenure - on one of the Android backend teams had barely heard of the name and wasn't sure what it was when I brought it up 2 years ago. Linux containers including Docker are absolutely widespread as I understand it, though.
  - tossaway9000 5y ago
    I second this, "google's problems are not your problems"

DaiPlusPlus 5y ago

Only if those packages' post-install scripts only mutate their own node_modules directory contents - and I can see this quickly falling-apart as soon as the team's dev-boxes becomes a heterogenous environment (e.g. someone using Ubuntu-on-WSL onboarding an all-M1 Mac team). Anyway, it's a given that I disagree with the article's specific point (i.e. to commit node_modules to source-control), however I am sympathetic to arguments about avoiding another left_pad incident, but there are better solutions to that then simplistically committing node_modules: 1. package-lock (though this is an incomplete solution: it helps to protects you from vague dependency version numbers (as it uses cryptographic hashes), but it doesn't store a copy of the npm package, and you need to make sure everyone is using the exact same npm/node tooling versions otherwise your package-lock file will be clobbered by different users checking-in wildly different `lockfileVersion` versions. 2. git LFS: every so often (once a month or so?) in a separate directory off-to-the-side, add a heavily compressed 7z LZMA archive of a snapshot of your node_modules directory (ideally in a known-good-state). This allows you to keep a repo-local copy of your important dependencies without it cluttering up your commits. While these would be monthly updates - and your actual package.json/package-lock.json dependencies may change daily or weekly - in the event of catastrophe it won't be too much work to track-down any missing dependencies or to revert the deps back to the last known-good LFS file. 3. Use tools like `offline-npm` and Verdaccio, which are NPM caching proxies. If this was 2019 and everyone was working in a central office then you'd run Verdaccio on a single box in your LAN and have everyone configure their NPM clients to route through that box, which then stores every package ever requested - you could presumably run a cron-job to ensure that package cache is backed-up somewhere safe, maybe even with git-LFS as discussed above.

3np 5y ago
> the exact same npm/node tooling versions I've only ever had issues with differing major versions. That is, sharing lock-files between any node v14.x should work, but expect things to break if you go to v16.