4 ms·

> it's not necessarily uncommon for JS developers to include node_modules in their git repos It's highly uncommon, and I've never seen an active, maintained, o

by pitaj 8y ago

> it's not necessarily uncommon for JS developers to include node_modules in their git repos It's highly uncommon, and I've never seen an active, maintained, or popular project with it.

danShumway 8y ago
It's become less popular with the introduction first of ``shrinkwrap`` and then ``package-lock.js``. At one point in time, it was recommended behavior in the official NPM documentation for site deployments, because there wasn't a way to checksum dependencies. They've since switched to recommending private repositories like Artifactory instead, which to be fair is usually better for very large organizations nowadays. But that wasn't always the case, and even as recent as 2013, it was the flat-out prevailing advice from package managers like Bower, and there are organizations who are still using and maintaining codebases that were set up in 2013. You won't see a lot of projects on Github that rely on it, because: A) Usually Open Source projects are designed to be built on multiple environments/OSes. B) The majority of Open Source Javascript projects are designed to be installed via NPM anyway, and of course you wouldn't include dependencies for something like that. However, you want to be careful not to make the mistake of assuming that every project has the same concerns as a standard Open Source project. Especially if an Org is going all in on standardizing dev environments through Vagrant or Docker, the question becomes, "why would you want an extra checkout/build step on top of that?"
nojvek 8y ago
to handle a static state of dependencies, usually a package-lock or a yarn.lock file is committed to the repo. That is the usual way to freeze the dependency tree.
- danShumway 8y ago
  Freezing a dependency tree isn't the point. The point is to avoid making a network request and to know that your dependencies will still be there 5 years from now. Remember that one of the benefits of Git is that it's distributed. Even if you are hosting your own npm mirror, relying on it gets rid of that distributed advantage. It doesn't help you to be able to clone from the person next to you if you can't build without making a network request. I'm not saying that this should be the norm for everyone. It obviously shouldn't be the norm for libraries. But it's not inherently a crazy or harmful idea.

by pitaj 8y ago

> it's not necessarily uncommon for JS developers to include node_modules in their git repos It's highly uncommon, and I've never seen an active, maintained, or popular project with it.

danShumway 8y ago

It's become less popular with the introduction first of ``shrinkwrap`` and then ``package-lock.js``. At one point in time, it was recommended behavior in the official NPM documentation for site deployments, because there wasn't a way to checksum dependencies. They've since switched to recommending private repositories like Artifactory instead, which to be fair is usually better for very large organizations nowadays. But that wasn't always the case, and even as recent as 2013, it was the flat-out prevailing advice from package managers like Bower, and there are organizations who are still using and maintaining codebases that were set up in 2013. You won't see a lot of projects on Github that rely on it, because: A) Usually Open Source projects are designed to be built on multiple environments/OSes. B) The majority of Open Source Javascript projects are designed to be installed via NPM anyway, and of course you wouldn't include dependencies for something like that. However, you want to be careful not to make the mistake of assuming that every project has the same concerns as a standard Open Source project. Especially if an Org is going all in on standardizing dev environments through Vagrant or Docker, the question becomes, "why would you want an extra checkout/build step on top of that?"

nojvek 8y ago

to handle a static state of dependencies, usually a package-lock or a yarn.lock file is committed to the repo. That is the usual way to freeze the dependency tree.

danShumway 8y ago
Freezing a dependency tree isn't the point. The point is to avoid making a network request and to know that your dependencies will still be there 5 years from now. Remember that one of the benefits of Git is that it's distributed. Even if you are hosting your own npm mirror, relying on it gets rid of that distributed advantage. It doesn't help you to be able to clone from the person next to you if you can't build without making a network request. I'm not saying that this should be the norm for everyone. It obviously shouldn't be the norm for libraries. But it's not inherently a crazy or harmful idea.