To check node_modules or not

Who puts their node_modules into source control and who doesn't.

It's been asked before, but this is more a show-of-hands question.

I'm fighting the corner to put them into SC and wondered what everyone else is doing.

This question and answers mentions pros and cons and has some nice links.

> Who puts their node_modules into source control and who doesn't.
>
> It's been asked before, but this is more a show-of-hands question.
>
> I'm fighting the corner to put them into SC and wondered what everyone else is doing.
>
> This question and answers mentions pros and cons and has some nice links.

I do not.

I'm happy with npm pack to generate deployable artifacts.

Who puts their node_modules into source control and who doesn't.

It's been asked before, but this is more a show-of-hands question.

I'm fighting the corner to put them into SC and wondered what everyone else is doing.

I check node modules into Git. Also, I do not keep node_modules local within the app directory structure, but instead I use NODE_PATH. My reasons are simple: (1) my app’s external dependencies should be kept as minimal as possible, (2) disk space may be cheap but maintaining separate versions of modules is not, so a common node_modules across apps accessed via NODE_PATH is better for me.

I do not. External modules are not source I am controlling

I use npm shrinkwrap to ensure the exact same version is deployed.

I do commit them before deploy, but I do ***NOT*** commit them to the
dev branch (usually master).

Use a mirror branch containing the exact same source as master, but
with dependencies added, using git commit-tree.

Indirectly, anyhow, I use strong-build:
https://github.com/strongloop/strong-build/#commit-command, if you are
getting pressure to commit deps, use slb to avoid the madness of
100,000s of lines of thirdparty code in your working branches...

Some more discussion here:

http://strongloop.com/strongblog/node-js-deploy-production-best-practice/

shrinkwrap is guaranteed to fail when npm is down or unreachable

I do not.

I have a Jenkins building my apps, running tests and then calling `tar`

I deploy the tarballs.

Also do not. Correct me if I'm wrong, but don't some module compile differently

based on the system? I seem to remember running into a problem with modules

compiled installed on OSX (because that's what I develop on), and failing

in production/staging because that was running some linux. 

That's one of the things we'll need to test for.

It's interesting that there's no one clear answer.

Also do not. Correct me if I'm wrong, but don't some module compile differently

based on the system? I seem to remember running into a problem with modules

compiled installed on OSX (because that's what I develop on), and failing

in production/staging because that was running some linux. 

Indeed, yes, since modules can produce binaries and compiled libraries. In my case, I have separate repos for node modules per platform.

We put everything into svn, node_modules included. Didn't find it worth the debate over what to do and the size is not a concern. In the case that we want to make a custom change without particpating in pull-requests or "whatever" that may come up, we treat our code as part of "our" company foundation and may come in need of rollback or what have you of version control.

>> Also do not. Correct me if I'm wrong, but don't some module compile
>> differently
>> based on the system?
<adrian.lynch@concreteplatform.com> wrote:
> That's one of the things we'll need to test for.
Yes, so the build process should do an `npm install --no-scripts`, and
then should pack up the addon c++ code, but NOT the compiled .node
file (which shouldn't exist, anyway, if you used `--no-scripts`).

slb does this: https://github.com/strongloop/strong-build#install-command

On the receive side the package should be prepared to run using npm
rebuild (which will involve *no network access*).

strong-pm does this on receive and redeploy of an app:
https://github.com/strongloop/strong-pm#life-cycle