CODEWITHSUNDEEP
gitgruntjs
bman
bman

Reputation: 5235

What should I do with Grunt's node_modules directory when I am publisihing my project to GitHub?

This is my first project using Grunt and Git. In my project I have '*node_modules*' directory that I created by command 'npm install grunt'. Now I want to publish my project to GitHub.

Should my project contains 'node_modules' or I should omit it? I am afraid that it makes the project scary for a developers who are unfamiliar with Grunt. In fact I am puzzled why you should install grunt for each project separately. Why it is not possible to install it globally?

Here is my installation: grunt-contrib-concat, grunt-contrib-jshint, grunt-contrib-qunit, grunt-contrib-uglify, grunt-contrib-watch.

Upvotes: 5

Views: 1637

Answers (2)

Florian
Florian

Reputation: 471

@"The only sensible reason to commit node_modules, IMO, is with a private application and repo intended to be deployed to production."

I started with never committing my node_modules into repo and only commit changes in package.json. But turned out thats a really bad idea for a project with multiple developers and a handfull of experimental feature-branches. As the node_module folder is not versioned with git you end up needing to run npm install on every branch switch, because modules can differ between versions. A real nightmare...

You will end up hearing "This crap doesn't work again!!", Only because one had updated a node-module in a feature branch. So i now recommend to include node_modules for projects with multiple developers and branches. Takes away a lot of pain...

EDIT: Just want to add some other things to keep in mind with checked-in/not checked in node-modules i had to ( painfully ) learn:

  1. Always lock-down your versions in package.json - which means basically removing all modificators in front of your packages version numbers ( like: ~, >, * and whatever possible ) If you have someone run npm install, you want them to get EXACTLY what you have ( Semantic-Versioning in theory is great and all, but sorry it's just not reliable, and you never/ever want packages to be updated without your knowing ). Otherwise just watch the world burn over and over again...

EDIT (28.02.2018): This is not longer needed - as in the new versions both npm- and yarn-package manager produce a .lock-file on installation - defining the exact installed package-versions - which can be commited and used by other developers.

  1. If working in a mixed OS Envirement there are some problematic grunt- packages which should only be checked in with caution, for instance grunt-imagemin, which can hinder checkouts on windows, using msysgit because their paths is to long. Filename too long in git for windows
  2. I found it is best practice for me to put my workflow automation and the according npm package into its own subfolder/repository for reusability and better project maintenance - because it keeps the automation modules from mixing with actual nodejs application-packages.

Upvotes: 3

Kyle Robinson Young
Kyle Robinson Young

Reputation: 13762

The reason you should not install grunt and grunt plugins globally is because then you could only have 1 version of each installed at a time. While working with a team, it also means every single member of your team must be running the same version of grunt and each grunt plugin.

Coordinating these versions with a team and switching versions as you jump to different projects is a nightmare. The solution, install everything locally. It's just file space and most modules don't take a whole lot of space.

Most people don't commit their node_modules folder into github. Each dependency listed in your package.json can be installed again by typing: npm install in the same folder.

Use npm install grunt --save-dev to save to your package.json as you install plugins and modules.

The only sensible reason to commit node_modules, IMO, is with a private application and repo intended to be deployed to production. Where you want to be sure your dependencies are locked down and not breaking something upon push. There are still other strategies to avoid committing node_modules, even with this use case though (such as npm shrinkwrap).

In short:

  • If you're deploying an app and paranoid about locking down your deps, commit your node_modules.
  • Everything else, dont commit your node_modules.

Upvotes: 7

Related Questions