116

I'm new to npm and don't really understand what should go into dependencies vs. devDependencies. I know that for testing libraries they should go into dev, but how about for things like babel and webpack? Should they be in dev too, because they're only used to transcompile es6 and JSX into vanilla JS? My understanding is that when you deploy to heroku, it do the transcompiliation with the necessary libraries already, so there's no need to host them on production?

  "dependencies": {
    "babel-core": "^6.7.7",
    "babel-eslint": "^6.0.4",
    "babel-loader": "^6.2.4",
    "babel-plugin-react-transform": "^2.0.2",
    "babel-plugin-transform-object-rest-spread": "^6.6.5",
    "babel-plugin-transform-react-display-name": "^6.5.0",
    "babel-polyfill": "^6.7.4",
    "babel-preset-es2015": "^6.6.0",
    "babel-preset-react": "^6.5.0",
    "bootstrap": "^3.3.7",
    "css-loader": "^0.23.1",
    "es6-promise": "^3.2.1",
    "eslint": "^2.9.0",
    "eslint-plugin-babel": "^3.2.0",
    "eslint-plugin-react": "^5.0.1",
    "express": "^4.13.4",
    "extract-text-webpack-plugin": "^1.0.1",
    "file-loader": "^0.9.0",
    "lodash": "^4.15.0",
    "react": "^15.0.2",
    "react-addons-css-transition-group": "^15.0.2",
    "react-dom": "^15.0.2",
    "react-redux": "^4.4.5",
    "react-transform-catch-errors": "^1.0.2",
    "react-transform-hmr": "^1.0.4",
    "redbox-react": "^1.2.3",
    "redux": "^3.5.2",
    "redux-form": "^6.1.0",
    "rimraf": "^2.5.2",
    "style-loader": "^0.13.1",
    "webpack-dev-middleware": "^1.6.1",
    "webpack-hot-middleware": "^2.10.0"
  },
  "devDependencies": {
    "babel-register": "^6.9.0",
    "chai": "^3.5.0",
    "mocha": "^2.5.3",
    "sinon": "^1.17.4",
    "webpack": "^1.13.2"
  }
stackjlei
  • 9,485
  • 18
  • 65
  • 113
  • http://stackoverflow.com/questions/18875674/whats-the-difference-between-dependencies-devdependencies-and-peerdependencies . This will give u some required clarity ! – semuzaboi Jan 25 '17 at 08:11

3 Answers3

102

The babel and webpack packages will go into the devDependencies section because these packages are used in when transpiling and bundle-ing your code into vanilla javascript in the bundle.js & etc file(s).

In production you will run your code off the bundle.js build/generated code will not require these dependencies anymore.

Taysky
  • 4,331
  • 2
  • 20
  • 28
Zohaib Ijaz
  • 21,926
  • 7
  • 38
  • 60
  • In production also, the build would be transpiled using babel only right?Can you please help me understanding this? – Harkirat Saluja Dec 27 '16 at 14:15
  • 4
    In production , your build or deploy folder will have content that are already transpiled by babel to ES5 . So you wont be actually needing them to run your application . – semuzaboi Jan 25 '17 at 08:09
  • 55
    One exception is babel-polyfill since polyfill is required at runtime: https://babeljs.io/docs/usage/polyfill/ – HaoCS Mar 31 '17 at 17:22
  • 3
    @HaoCS I've seen Babel's docs say to put `babel-polyfill` in dependencies, but I don't understand why. Won't the bundle include it once a build is run? I see no reason it can't be in devDependencies. Would love more insight. – The Qodesmith Apr 02 '18 at 00:03
  • 14
    In response to Harkirat's question (and the comment answering it), there are some assumptions being made about how you deploy. When people say "Babel is a dev dependency", they're expecting you to commit your Babel-compiled code into Git (or whatever you use) and then deploy that compiled code to your server. In that scenario Babel is a dev dependency, because it never runs on the server. But if you instead commit the normal code, and run Babel on your sever, you probably don't want it as a dev dependency, since the server needs it. – machineghost Oct 02 '18 at 23:42
  • @machineghost Code is always compiled before running either on server or in case of static content e.g. a react website on S3 or firebase hosting. So babel is a dev dependency but someone else is reading this, kindly comment – Zohaib Ijaz Oct 03 '18 at 08:15
  • 4
    While this totally makes sense for NodeJs env, one can think of it differently when it comes to a frontend project. The fact is that for a frontend project you will need no packages, only the bundle file. Doesn't matter whether it's Webpack, Babel, or React. In my project, I store everything that's required to build a production bundle in `dependencies` and all the tools I use in dev in `devDependencies`. This essentially means that Webpack ends up in dependencies, jest - in devDependencies. – Aleksandr Oct 09 '20 at 21:56
58

Despite what basically everyone says, I'm going to offer a piece of sanity... it's really quite simple:

Is your project going to be npm installed by another project? a.k.a are you authoring a npm module? will it end up in another projects package.json?

No?

Then put everything in dependencies.

Yes?

  • dependencies: Things you want downstream consumers and project developers of your project to have installed:
  • peerDependencies: Things your downstream users need to make sure they have installed
  • bundleDependencies: Things your downstream users will need, and won't need to install separately because when you npm publish, these will be "bundled" with your package.
  • optionalDependencies: Things that are nice to have but the absence of will not cause fatal error
  • devDependencies: things only used while working on your project.

The short of it is this: modules do not magically get installed differently. They either get installed or they do not.

Chris Vincent
  • 123
  • 12
airtonix
  • 4,772
  • 2
  • 38
  • 36
  • 30
    For a regular app (not an npm lib), putting everything in `dependencies` means your development tools will be deployed with your app in production. Bad idea. – jfroy Sep 19 '19 at 13:46
  • 3
    @jfroy, could you please confirm this ? like a link of source. I remember one of our js dev mentioned that when webpack build and bundle js code, it will check if a package been imported or not, then decide that if or not it should be packaged. However, the package babel will unlikely been import and used in application code, right ? In this case, even babel is added into dependencies, then it will not be packaged, right ? Thank you – Jeff Chen Sep 20 '19 at 00:00
  • 3
    @JeffChen, take a look at the definitions from npm docs: https://docs.npmjs.com/files/package.json#dependencies. They specifically warn not to put transpilers in dependencies. Tree shaking as applied by Webpack and other packagers will indeed remove unused code in production builds, thereby removing any wrongly assigned dev dependencies, but nothing in this answer clearly states that this is what they rely on to justify an ill-defined package.json. – jfroy Sep 23 '19 at 21:37
  • 4
    @jfroy we use docker multistage builds. So none of your concerns are relevant. In fact the only thing that ends up in production is the output js/css/png/etc bundle. Really. the effort you go to in order to work out this separation of frontend dependancies is not even close to worth the reward. – airtonix Jan 26 '20 at 00:46
  • The separation matters if you deploy to serverless, devDependencies do not get included in the zip while dependencies do. Meaning that if you add everything to dependencies you will end up reaching lambda layer size very quickly – Marco Acierno Aug 28 '20 at 13:54
  • Doing this would make it impossible to audit only production modules for vulnerabilities – OZZIE Jul 02 '21 at 06:42
  • @airtonix: Not _everyone_ is using Docker Multistage builds, however. Marco also made a good point about serverless deployments. There IS a good reason for devDependencies to exist. I also wouldn't agree with what you're suggesting about whether your project is an NPM module or not; that's irrelevant. Dependencies are things that your production code rely on to function. Dev dependencies are things that your compiler/parser/minifier/prettifier/linter rely on: specifically, things which are needed for preparing a build. NOT the build itself. – Crates Oct 21 '21 at 17:19
  • @Crates yep, all you've done is describe why your brain needs that separation, learn to let go of that OCD. Where as what I've described is that you really don't need to care about that, nodejs engine doesn't care npm only behaves differently if you're installing your own project or another module, hence the authoring vs not authoring aspect. Honestly, they only thing you should care about with regards to your devtoolchain is the npm scripts. Finally, this question clearly states outputting JSX so serverless is irrelevant, but if you really must waste time bikeshedding, use a tool like nx. – airtonix Feb 05 '22 at 23:12
-6

Dev dependency is which only use for the development server, these are devDepedency: All the packages which are not using in source code or imported are devDependencies

"babel-cli": "^6.26.0",
"babel-core": "^6.26.0",
"babel-loader": "^7.1.4",
"babel-preset-env": "^1.6.1",
"babel-preset-react": "^6.24.1",
"clean-webpack-plugin": "^0.1.19",
"copy-webpack-plugin": "^4.5.1",
"css-loader": "^0.28.11",
"file-loader": "^1.1.11",
"html-webpack-plugin": "^3.2.0",
"mini-css-extract-plugin": "^0.4.0",
"node-sass": "^4.8.3",
"optimize-css-assets-webpack-plugin": "^4.0.0",
"prop-types": "^15.6.1",
"sass-loader": "^7.0.1",
"style-loader": "^0.21.0",
"uglifyjs-webpack-plugin": "^1.2.5",
"webpack": "^4.6.0",
"webpack-cli": "^3.1.1",
"webpack-dev-server": "^3.1.9"
Shubham Laad
  • 40
  • 4