4 ms·

How are all of you using any npm-based system combined with a continuous integration or clean build environment? It seems that a simple yeoman/grunt setup that

How are all of you using any npm-based system combined with a continuous integration or clean build environment? It seems that a simple yeoman/grunt setup that just preprocesses some HTML and JS takes... a very long time. A minute or two just for the actual work. Plus 5-15 minutes for npm to make a thousand requests and write 10K+ files to the filesystem. I hack around it by keeping node_modules around as a special resource on a custom build server and symlinking it in, but that wouldn't work with a proper "start from zero" build system.

lucaspiller 12y ago
Why does it matter if your build system takes a while? You shouldn't be pushing it to there until you are happy it works locally, at which point you can move on to the next task and forget about it.
tieTYT 12y ago
> It seems that a simple yeoman/grunt setup that just preprocesses some HTML and JS takes... a very long time. I have not experienced this. I built a 15k+ line CoffeeScript app. Every time a file changed it would compile it to JS and run thousands of unit tests in ~1 second. As for the clean NPM... I never deleted that directory. I believe I read an article somewhere that you should actually commit your module dir. Maybe that's no longer in vogue though?
Kudos 12y ago
Both Travis CI and Circle CI cache your node_modules directory between builds. If you don't change your package.json, it just uses that cache instead.
doublerebel 12y ago
1) We have our own private npm that can optionally include a caching layer. This has been invaluable since the beginning of our company to manage internal dependencies. 2) We use StriderCD, the self-hosted CD/CI, and it too supports caching node_modules. 2 minutes is a 'long' time for us from git push to autodeploy. 3) We use gulp and npm always. Grunt and bower are a mess. EDIT: Also, we npm shinkwrap projects. It avoids numerous issues and makes module caching a natural part of the process.
- jessaustin 12y ago
  Grunt and bower are a mess. grunt has its issues, but you are correct that bower is truly a mess. "Let's do one of the many jobs that npm (the tool we use to install bower) already does, but not as well!" No thanks.

lucaspiller 12y ago

Why does it matter if your build system takes a while? You shouldn't be pushing it to there until you are happy it works locally, at which point you can move on to the next task and forget about it.

tieTYT 12y ago

> It seems that a simple yeoman/grunt setup that just preprocesses some HTML and JS takes... a very long time. I have not experienced this. I built a 15k+ line CoffeeScript app. Every time a file changed it would compile it to JS and run thousands of unit tests in ~1 second. As for the clean NPM... I never deleted that directory. I believe I read an article somewhere that you should actually commit your module dir. Maybe that's no longer in vogue though?

Kudos 12y ago

Both Travis CI and Circle CI cache your node_modules directory between builds. If you don't change your package.json, it just uses that cache instead.

doublerebel 12y ago

1) We have our own private npm that can optionally include a caching layer. This has been invaluable since the beginning of our company to manage internal dependencies. 2) We use StriderCD, the self-hosted CD/CI, and it too supports caching node_modules. 2 minutes is a 'long' time for us from git push to autodeploy. 3) We use gulp and npm always. Grunt and bower are a mess. EDIT: Also, we npm shinkwrap projects. It avoids numerous issues and makes module caching a natural part of the process.

jessaustin 12y ago
Grunt and bower are a mess. grunt has its issues, but you are correct that bower is truly a mess. "Let's do one of the many jobs that npm (the tool we use to install bower) already does, but not as well!" No thanks.