Does it work across x86, 64, arm, linux, mac and windows?
Some modules straight up download binaries so I don’t see being so straightforward.
We check our node_modules folder into source control
31–40 of 241 posts
Re: We check our node_modules folder into source control
#32Does the Chrome DevTools team use Google's big monorepo and all the tooling around it? If so, that puts the author in a different situation than the vast majority of devs.
Chrome DevTools has their own separate repo
* https://developer.chrome.com/docs/devtools/
* It's mirrored on GitHub: https://github.com/ChromeDevTools/devtools-frontend
* And look, THAR SHE BLOWS: https://github.com/ChromeDevTools/devtools-frontend/tree/mai...
Re: We check our node_modules folder into source control
#33The GitHub mirror of the Chrome DevTools repo has the node_modules folder here: https://github.com/ChromeDevTools/devtools-frontend/blob/mai...
But there is nuance (there always is...), the README file in node_modules is here: https://github.com/ChromeDevTools/devtools-frontend/blob/mai... - and it makes it clear the only NPM dependencies used by the build-system or infrastructure is meant to be checked-in. Other NPM packages should not.
----------
In conclusion: the linked blog-article is clickbait that misrepresents how the Chrome team manages their dependencies.
Re: We check our node_modules folder into source control
#34Earlier quoted context omitted.
No it's not. They are talking about their personal preference and it has nothing to do with real life employers.
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
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.
Re: We check our node_modules folder into source control
#35Earlier quoted context omitted.
Check in your lock file.
Done. Then I delete it, and `npm install`. Then commit. The majority of people I have worked with do that. On Friday some dude was saying "shrinkwrap v2 is not shrinkwrap v1" and the advice was "delete it and npm install" then commit. (Payment company software manager).
use yarn instead, the lockfile is much better.
Re: We check our node_modules folder into source control
#36Earlier quoted context omitted.
Check in your lock file.
Done. Then I delete it, and `npm install`. Then commit. The majority of people I have worked with do that. On Friday some dude was saying "shrinkwrap v2 is not shrinkwrap v1" and the advice was "delete it and npm install" then commit. (Payment company software manager).
Anyone recommend a build check to block PR's from including fully rebuilt lockfiles? Other than a high LOC, it's too easy for this to slip through.
Re: We check our node_modules folder into source control
#37I mean come on now. You have internet? Good. Then u will be able to both run npm & git commands. Plus npm has cache. Why burn internet payload for no reason?
Re: We check our node_modules folder into source control
#38Does it work across x86, 64, arm, linux, mac and windows? Some modules straight up download binaries so I don’t see being so straightforward.
No, and that detail is dangerously missing from the advice. lol
Anyone that does this and has teams on Mac, Windows and Linux will find out how crappy this is very quickly.
Re: We check our node_modules folder into source control
#39This very week I was dealing with my artifacts exploding in size because AWS got 429s from GitHub. Then Composer pulled from source and there were so many extra files and SCM folders we exceeded the max artifact size. Another idea is to host your own package cache. That would be my preference where SCM size prohibits checking in dependencies themselves.
> Another idea is to host your own package cache.
This makes most sense, and is the common solution at larger companies. Right tool for the job and all that.
Re: We check our node_modules folder into source control
#40This really only works if you avoid native modules. I'm not sure why the author didn't mention native modules as it's a pretty big deal in this context.