Publish NPM package with only non-bundled dependencies

Question

Lets say we're developing a small javascript library L .

The code is in ES6. To use some utility function, like debounce , we install lodash as a dependency.

At build the webpack transpiles the code, bundling the tree shaked lodash code, and we end up with a nice little javascript file we want to publish and share as a npm package.

Now, the package.json file lists lodash as a dependency. But that is only true at build time, it is not really needed in production.

What's the proper way to handle this kind of situation? Does it make sense to consider lodash a devDependency? As such, only webpack's externals would be "real" dependencies?

Or should we somehow tamper the package.json file before publishing it?

Do you know any real examples of projects handling this question?

Answer 1

Webpack "merges" the code of the project with that of the used code of the non-external dependencies into some bundle.js file. This file is then published to NPM, along with a package.json file, which lists all of the dependencies, independently of these being external or embedded.

All of the code of packages referenced in dependencies (or optionalDependencies , or peerDependencies ) is expected to be "production" code. While code in devDependencies is expected to be used only at "development" time, and is thus "development" code. Under this principle, I believe that it would be incorrect to declare non-external dependencies as development dependencies.

However, if all dependencies, embedded or external, are declared equally in the published package.json file, there is no way for a runtime environment to know which are the real dependencies that need to be made available to the package — the ones that the package will import at runtime and which better be available.

For the Node.js environment, bundles and Webpack are not normally used, so this never came to be an issue — all dependencies are always installed (never merged/bundled).

However, if you use the package.json file to drive some web-packages runtime environment, the way that dependencies are currently included in published package.json is not suitable.

You might want to take a look at Pika Web's devDependencies package.json property, which aims to solve a comparable problem (even though their mojo is "a future without Webpack"). They also introduce the concept of publishing a different package.json file than that which is checked-in (tampering the package.json before publishing, as you say).

Interestingly, it looks like a related tool, Pika Pack, caught the attention of NPM folks and is being considered to become part of NPM . So, maybe , NPM has become aware of the specific package format needs of web projects' workflows.