Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

Tags:

git

gruntjs

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.

like image 452
bman Avatar asked Feb 01 '14 05:02

bman


People also ask

Should you upload node_modules to github?

On the other hand, folder node_modules should not be committed to Git. Apart from their big size, commits including them can become distracting. The best solutions would be this: npm install should run in a CI environment that is similar to the production environment.

What is node_modules directory?

A node_modules directory contains all the React dependencies packages: react , react-dom , and their transitive dependencies like webpack , babal , rxjs , ESLint , etc., to build and run a React project.

Should I put node_modules in Gitignore?

The default option is here not to commit the node_modules folder, you should instead add it to the . gitignore file.

What is stored in the node_modules directory of your node application folder?

The node_modules folder contains every installed dependency for your project. In most cases, you should not commit this folder into your version controlled repository. As you install more dependencies, the size of this folder will quickly grow. Furthermore, the package-lock.


2 Answers

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.
like image 152
Kyle Robinson Young Avatar answered Sep 28 '22 01:09

Kyle Robinson Young


@"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.
like image 28
Florian Avatar answered Sep 28 '22 00:09

Florian