1

In your package.json you have dependencies and devDependencies.

{
  "devDependencies": {
    "webpack": "^4.42.1"
  },
  "dependencies": {
    "react": "^16.13.1"
  }
}

I understand that:

  • dependencies are deps that your app needs to run
  • devDependencies are deps that you only need during development

But, why do they need to be split up like that? What are the benefits?

What happens if I do this?

{
  "dependencies": {
    "react": "^16.13.1",
    "webpack": "^4.42.1"
  }
}

Are there any performance hits? Would splitting up the deps only matter if I wanted to publish a module?

This question has nothing to do with: What's the difference between dependencies, devDependencies and peerDependencies in npm package.json file?

That question is asking what dependencies and devDependencies are. I clearly stated what they are above.

This question is about why you would want to split deps like this at all. It seems like some people build their app in their prod server. I usually build offline and just ship the index.html and main.js artifacts. So some of these points don't apply to my current situation.

Also, after a little more testing, it kinda seems like your devDependencies don't actually end up in your main.js bundle file. At least in the way I have my project setup, I didn't see any size difference between splitting my deps and having them all under dependencies. And because I just ship the build artifact, this doesn't affect my production experience at all.

425nesp
  • 6,936
  • 9
  • 50
  • 61
  • 2
    Does this answer your question? [What's the difference between dependencies, devDependencies and peerDependencies in npm package.json file?](https://stackoverflow.com/questions/18875674/whats-the-difference-between-dependencies-devdependencies-and-peerdependencies) – ggorlen Apr 14 '20 at 01:54
  • I don't think so. I know what they _are_, but I want to know _why_ they exist at all and what benefits they provide. Everyone seems to say "these are for your app and these are for dev", cool, but _why_ do we need to split them up like that? – 425nesp Apr 14 '20 at 01:56
  • It seems rather self-evident that you'd potentially want a different set of packages for development vs deployment, no? Do you really want your production deploy to be bogged down installing and building tons of packages that are totally irrelevant and unused in the production build? See [this answer](https://stackoverflow.com/a/18875734/6243352) and [this answer](https://stackoverflow.com/a/18879864/6243352) from the dupe. – ggorlen Apr 14 '20 at 01:59
  • There are plenty of programming languages that do not split deps like this. From the ones I know, JS is the only one that does this. – 425nesp Apr 14 '20 at 02:02

2 Answers2

2

Having the two categories is helpful because you don't want development-time things being packaged with your code when you publish it. For example you might have some npm packages for development purposes (like jest, linting tools or prettier) but would not want those to be added to the code that others get when they install your package. It would make your package larger than it needs to be.

This is important if you will be making your code available for others to do an npm install of. Those that install your package don't need all of your development time modules since they're not relevant or used by your actual code.

'npm' is the Node Package Manager and to do its job of packaging node modules it needs to know what is needed to build the code, and what is needed at runtime when using the code. If you go to the project's git repository and clone it, you can do an npm install and get the development environment. That loads up all of the dependency modules into node_modules/. However you don't need all of that when you're using the module. When using the module, you just need the dependencies and not the devDependencies. It's here that npm needs to know the difference because its job is to handle the packaging of the module.

When you publish your module on npm (or to a locally managed npm repository) and other developers start using your module, they don't want to drag in all sorts of things that are only needed while developing the module. They want the leanest form of your module for it to do its job.

In other languages you might have a makefile that does your build, and knows to exclude the test folders, source folders, etc and only package up what's needed at runtime. For example with Java you may build a .jar file that excludes the development-only things like unit tests. Think of the package.json as the makefile and the devDependencies section as a hint to the builder of what to exclude when building the runtime component.

Always Learning
  • 5,510
  • 2
  • 17
  • 34
  • > if you are using webpack... don't want webpack to include a copy of itself... bloat I have webpack building a React app. I checked the size of `dist/main.js` with my deps split and again all under just `dependencies`. The size of the bundle seemed to be the same. Not sure if someone else could verify. – 425nesp Apr 14 '20 at 02:14
  • Not trying to say that splitting isn't a good idea. Just trying to learn what is actually happening. :) – 425nesp Apr 14 '20 at 02:14
  • the distinction between`dependencies` and `devDependencies` is completely orthogonal to the npm package publishing process. and webpack doesn't blindly import whatever you list as a dependency in your package.json file; it builds an asset graph starting with the entry point contained in its config. – Dan O Apr 14 '20 at 04:42
  • answer expanded a bit - hope it clarifies – Always Learning Apr 14 '20 at 10:59
-3

I guess maybe your npm projects are only frontend web projects, e.g. vue/react/angular related projects. If you never wrote a nodejs app, you are likely confused.

For these frontend web projects, it seems that there is no difference between dependencies and devDependencies. Because you just bundle all the dependencies into final output js file. Actually, after you installed all related dependencies under node_modules, you can even delete the items in dependencies in package.json file, and then you can build the project as usual.

A released frontend project is usually just one bundled js file deployed on web server, no need to build projects or install any depedencies. But imagine you are developing a nodejs project. A released nodejs app is the whole contents in the directory with package.json file. When running a nodejs app, you have to run npm install --production to install all dependencies before you can run the main js file of the package. devDependencies is not a must to run, but building and testing phase will need it.

xueluo
  • 1
  • 1