4 ms·

But you don’t have to commit or deploy the dependencies right? It’s just that size for the build isn’t it?

guessmyname 8y ago
> But you don’t have to commit or deploy the dependencies right? Yes, I have, otherwise I will impose Node.js + NPM as a dependency for my co-workers who — again — are not web developers, they just want to quickly modify one or two things and deploy without my involvement, so I have to build something as standalone as possible, this means (in this and other projects) that I have to commit the whole "node_modules" folder with the rest of the files. And if anyone thinks this is a weird requirement, I can tell you that last year I did some contractor work in four web agencies in San Francisco, and they all had a policy of "commit all the dependencies" because they wanted to "lock" the files to a specific version. They used to lock the dependencies using the "package.json" file, but after all the recent fiascos with NPM and their registry, they stopping relying on the constant download of these files during every deployment, something that we were considering even before the problems with NPM because downloading +200M of files for every execution of the test suite in the CI server was posing a significant cost for not reason. If NPM and their registry were more stable, I would just put everything in the "package.json" file and ignore the +100M of code in the dependency tree, but unfortunately, the Node.js is voting for a different philosophy that has been biting them for several years now, they still haven't learnt the lesson.
- acemarke 8y ago
  Committing your node_modules folder is definitely a bad idea. To me, the right answer is to use Yarn's "offline mirror" feature to cache the package tarballs themselves in your repo. They're smaller, it's a lot fewer files, and it's platform independent.
- philliphaydon 8y ago
  I'm so confused.
- brazzledazzle 8y ago
  I won’t knock anyone that does that, especially short term, since vendoring your libraries prevents build time dependencies outside of your control. But long term it might be worth looking at the NPM registry proxies that are out there.

> But you don’t have to commit or deploy the dependencies right? Yes, I have, otherwise I will impose Node.js + NPM as a dependency for my co-workers who — again — are not web developers, they just want to quickly modify one or two things and deploy without my involvement, so I have to build something as standalone as possible, this means (in this and other projects) that I have to commit the whole "node_modules" folder with the rest of the files. And if anyone thinks this is a weird requirement, I can tell you that last year I did some contractor work in four web agencies in San Francisco, and they all had a policy of "commit all the dependencies" because they wanted to "lock" the files to a specific version. They used to lock the dependencies using the "package.json" file, but after all the recent fiascos with NPM and their registry, they stopping relying on the constant download of these files during every deployment, something that we were considering even before the problems with NPM because downloading +200M of files for every execution of the test suite in the CI server was posing a significant cost for not reason. If NPM and their registry were more stable, I would just put everything in the "package.json" file and ignore the +100M of code in the dependency tree, but unfortunately, the Node.js is voting for a different philosophy that has been biting them for several years now, they still haven't learnt the lesson.

acemarke 8y ago
Committing your node_modules folder is definitely a bad idea. To me, the right answer is to use Yarn's "offline mirror" feature to cache the package tarballs themselves in your repo. They're smaller, it's a lot fewer files, and it's platform independent.
philliphaydon 8y ago
I'm so confused.
brazzledazzle 8y ago
I won’t knock anyone that does that, especially short term, since vendoring your libraries prevents build time dependencies outside of your control. But long term it might be worth looking at the NPM registry proxies that are out there.