Do you put Babel and Webpack in devDependencies or Dependencies?

javascript npm dependencies packages package-managers

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"
  }

stackoverflow.com/questions/18875674/… . This will give u some required clarity !

Taysky

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.

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 .

One exception is babel-polyfill since polyfill is required at runtime: babeljs.io/docs/usage/polyfill

@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.

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.

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.

Chris Vincent

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.

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, 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

@JeffChen, take a look at the definitions from npm docs: 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 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.

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

Shubham Laad

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"

Those are required to build the app. It all depends on where you build the app.

Do you put Babel and Webpack in devDependencies or Dependencies?

Follow WeChat

Want to stay one step ahead of the latest teleworks?

相似问题

Platform

Support

Contact US