Checking node_modules into git

[José F. Romaniello]

Hi all, I have read few times that is better to checking the dependencies folder into git when you are working on a project that must be deployed, it seems that this makes testing and maintainance easier. So, the advice seems "be flexible with the dependencies for libraries, and very strict for projects".

For me the pros are:

- dont have to blindly trust the correct use of semver from the package owner

- make sure everyone has the same versions

- probabily faster to deploy, since npm install will do nothing

The bigger cons I see is that i dont like something in GIT that can be auto-generated. It will happen almost for sure that someone will commit a change in the package.json updating the version of the dependency and forget about the node_modules or vicecersa. It will be easy to notice if it breacks a test but not sure who wants to be dealing with that after all...

Thoughts? experiences? 

Thanks!

[Domenic Denicola]

For me checking in a npm-shrinkwrap.json gives all of the advantages of checking node_modules into git, with none of the drawbacks. That's my preferred solution.

[Mikeal Rogers]

I wrote an article about it a year ago, it's still relevant.

http://www.mikealrogers.com/posts/nodemodules-in-git.html

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[Mariusz Nowak]

This is good approach, but only for final applications, you should never commit dependencies into repositories of resuable (generic) modules.

I have great experience with that, and to me it's the *only* way to assure that installation of application is straightforward and the only way to make sure that your project is installed in designated places as you expect.

First thing: You don't rely on npm repository state. That's not just about npm uptime, but mind that any package may be removed or replaced (even specific version of package may be replaced by the author with different code). Imagine that after one year of finished development you want to install project and you depend on npm state from year before, there's a chance that you'll run into problems.

Second thing: You don't rely on the network, therefore you can easily install your product being behind firewall which may block connection to npm repository.

[José F. Romaniello]

Thank you all.. All these are very good points and I didnt know about shrinkwrap! I will try it.

2012/12/27 Feross Aboukhadijeh <fer...@gmail.com>

There was a blog post on the node.js blog comparing the npm-shrinkwrap and node_modules approaches:

http://blog.nodejs.org/2012/02/27/managing-node-js-dependencies-with-shrinkwrap/

Basically, checking node_modules into git works fine until you need to use a binary module, or a module with a binary dependency. You don't want to check in binary files if your server is on a different platform than your development environment. You can hack around it by adding rules to gitignore the binary files and running "npm rebuild" when you deploy, but npm-shrinkwrap is cleaner and simpler, in my opinion.

Feross

 If you check in the binary, then your code won't run  actually be checking in binary filesyou use a binary 

[Marco Rogers]

Here's the article I wrote on checking in modules as well. I haven't really tried shrinkwrap, but it sounds like there are enough differences between the two approaches that you should explore both and see which one suits your needs best. I would employ shrinkwrap on a project where the deploy process was straightforward and the deps were very manageable. But as soon as any of that became a problem, I would move to checking in deps without thinking twice.

http://eng.yammer.com/managing-node-js-dependencies-and-deployments-at-yammer/

:Marco

[Austin William Wright]

Using git submodules is my preferred style when writing applications. That way you point to an exact source code tree, all the while you keep their respective commit histories. I have a Git program (in Node.js) that manages the submodules for Node.js dependencies, <https://github.com/Acubed/git-node>. I'd prefer to use it for libraries too, but it doesn't work out just exactly right yet (for development vs. production dependencies, etc).

No matter what, avoid checking in external projects to your source tree, you lose all their development history when you refer to a tree instead of a commit (as submodules do). If you must make modifications to the submodule, fork it and point to  your forked version (this is where submodules excel over using package repositories).

Austin Wright.

[Jacob Groundwater]

I have been warming up to the way Netflix does their deployments. Each update is a full image, packaged as an Amazon Machine Image, ready to be inserted into an auto-scaling group. This technique can be abstracted to any VM-style cluster however.

Since each images is pre-made, and ready to run on boot, all dependencies are pre-installed. There is no risk of NPM being down during a deployment, or a dependency version update occurring between testing and deployment.

If there is an error during the image creation, it can easily be re-run. There is no risk to the production environment.

You gain all the safety of having explicitly control over dependencies, but can keep generated code out of git.

I realize this is a rather large leap in deployment style, but I thought I would share.