Michael Scott Hertzberg

Posted on Aug 24, 2018

Demystifying `devDependencies` and `dependencies`

#webdev #opensource #npm #node

If you aren't familiar, devDependencies and dependencies are two properties that are added to package.json when a package is installed as a development dependency or a production dependency, respectively.

In the npm ecosystem packages are installed and consumed by requiring or importing them in files, or run in the command-line as binaries. When an application is fed into a module bundler, like Webpack or Rollup, all required dependencies are pulled together and bundled (as the name suggests). You should ensure that these packages are present in dependencies, as they're needed at runtime.

Development dependencies, or devDependencies are packages that are consumed by requiring them in files or run as binaries, during the development phase. These are packages that are only necessary during development and not necessary for the production build. Some examples of packages that would only be required during development are babel plugins and presets, test runners and linter packages.

Alternatively, there is a dependency that is necessary in both production and development. In this case, it can be added to dependencies, since dependencies are available in both production and development.

I hope this explanation helps with you in deciding whether to --save-dev or --save that package, next time.

Top comments (20)

Bek Saylor • Apr 18 '23

Hello, I am a newbie. I understand there are development and production files. Now I have taken a couple of tutorials and one person just used { nodemon server.js} to render the file while another tutorial showed my how to {--save-dev} which also renders the file.
Now when I use {--save-dev} is that for to be semantically correct or is it to be used with something like webpack only?

I am confused on why to use {--save-dev} and should we do it everytime, well unless it is production.

Michael Scott Hertzberg • Apr 30 '23 • Edited

This gets easily confusing. I've found it easier to digest to consider the two:

The system that your application is being deployed to (maybe a Lambda on AWS) will have a node_modules directory after npm install. When npm install is run, it installs both devDepdendencies and dependencies. npm install --production or NODE_ENV=production npm install will only install production dependencies listed in dependencies.
Webpack as a tool is used to optimize a hierarchy of files into concatenated smaller chunks and transformed to include any dependencies that have any sort of import or require code, will be part of the bundle. Webpack doesn't care if the import or require is in devDependencies vs dependencies.

Now an example use-case for going with semantics: If you happen to have a deploy process where there is concern for the size of the node_modules directory in a Lambda, as the file-system does have a limit that can easily be surpassed, it would be a wise decision to take advantage of npm install --production whereby the node_modules directory would be significantly smaller in size (but only if you semantically separated the correct dependencies and devDependencies). There otherwise would not be a shortcut for this. As mentioned earlier, Webpack doesn't care where in package.json the dependencies are listed. It's the cases where the semantics can scale.

Bek Saylor • May 1 '23

Thanks so much for your response, from what I am understanding, npm install —production only uses the dependencies in file, but the devDepdedencies install a lot more development dependencies if you use them or not.

draczihper • Jun 12 • Edited

Take it like this your are building a house and you use all tools that you have to use. The tools and materials that are still going to be there when you give it to the owner like bricks, cement, roof etc., those are in the same analogy, packages that are going to be used on production, hence npm install <package-name> --save should be used. The tools that are necessary for building the house, but not needed by the owner like the spirit level, wheelbarrow, tape measure, spade etc., those are in the same analogy the packages and plugins that are not useful in production but useful while coding since the finished product is already made, hence npm install <package-name> --save-dev should be used.

Mehdi M • Apr 9 '21

As i searched about it a lot, I found this article very useful, thanks. Now i have a question, how could I find out, that a package, is necessary for production and should be in dependencies? or not necessary for production and devDependencies is suitable??

Michael Scott Hertzberg • Oct 28 '23

Best way to think about it, is to first consider the entire dependency tree of your bundled, optimized, minified, and deployed application. In order for that code to function properly somewhere in the cloud, it's going to expect certain libraries/packages to be available for it to run. These would be necessary "dependencies." The packages used to run tests (jest), bundle (webpack), optimize (babel) and minify (esbuild) your code, are required/necessary libraries/packages for the development phase of your applications lifecycle.

Mihail Malo • Sep 12 '18

The second paragraph is confusing.
Why should I have Webpack or something that webpack is bundling in dependencies? Both are often (there are exceptions) used only in development. Only server dependencies should be in dependencies?

Michael Scott Hertzberg • Sep 12 '18 • Edited

Hi Mihail,

I understand your confusion in the sentence when I say:

You should ensure that these packages are present in dependencies, as they're needed at runtime.

these packages refers to all required dependencies that your application needs at run-time. Not specifically Webpack or Rollup.

Mihail Malo • Sep 12 '18

Yeah, but I mean I put my webpack and clientside dependencies into devDependencies. And it works out great.

Michael Scott Hertzberg • Sep 13 '18

it works, but it's not semantically correct.

Mihail Malo • Sep 14 '18

Seems more semantic than downloading unused packages. 🤔
The less packages in production, the faster and safer 🤔
Maybe we should just Rollup our servers and not have runtime dependencies at all 🤔

amir • Sep 18 '22

Awesome 👏

Thanks Michael

VM • Aug 25 '18

Question: if I have code referencing a devDependency. And that code continue to exist on prod, my app would break, correct? Then should I remove my code when deploying?

Alan Aasmaa • Aug 25 '18 • Edited

Also one option would be to check envoriment. And when building for production uglify removes unnecessary code. See more in uglify documentation.

I actually use this also for building multible different sites from one source.

Michael Scott Hertzberg • Aug 25 '18 • Edited

Hi Vic,

If your code references a dependency, it should be in dependencies, otherwise your app will break. You'd generally reserve devDependencies for things like babel plugins and presets, test runners. Things that are needed to compile your application.