npm Community Forum (Archive)

The npm community forum has been discontinued.

To discuss usage of npm, visit the GitHub Support Community.

peerDeps + deps VS peerDeps + devDeps (Best Practice?)

What are npm-experienced people thinking about mixing peedDependencies with dependencies or devDependencies?


peerDependencies should have an as loose as possible semver, and ensures that a warning is raised when these deps are not satisfied by the project. It will not install the deps automatically (from NPM3 on), and the user has to install them manually.

In a context of a library_foo that is dependent on jQuery, I want the less cumbersome setup for the users requiring the library in their projects.


Actual Questions…

Would be nice to have some clarity and define the best practice in this case. Documentation is a little outdated and doesn’t mention cases where peedDeps are mixed with other deps directives.

Any idea or suggestion?
Your experience?

Sounds like a judgment call depending on the relative merits and pitfalls between the two proposed alternatives. For JQuery I would personally favor a peerDep for the following reasons:

Thanks for your answer @brodybits. Yes, I am trying to get to a best practice for the peerDeps case (since many people/blogs/devs have different, sometimes confusing, opinions).

I agree, peerDependencies is the main fixed requirement. I am never gonna remove that.

Just, after moving the dep solely in there, old (NPM > 2) users relying on automatic installation of the library_foo deps will suddenly have additional (WARN and) requirements to satisfy on their project (installing jQuery manually); even if:

My main question mark is actually about what to use additionally to peerDependencies:


Or are dependencies and peerDependencies intended to be mutually exclusive?

(I can’t find an answer to this anywhere on the net or the NPM docs or the Yarn docs)

In your case I would put it (JQuery) in peerDepencies and devDependencies, assuming there is actually a reason such as the existence of a working test suite for adding it to devDependencies. I would see the following mutually exclusive choices for each possible dependency:

I hope this answers your question. I am still not an expert at npm internals, just giving the answers that make the most sense to me given my experience to date. I remain hopeful that a npm expert will be able to confirm. You may be able to get better answers from Stack Overflow.

I am also still not an expert in the existing npm documentation but would have to agree with you that it should be improved in this respect. I cannot promise when I would have time to better verify the actual behavior and contribute documentation. If you have a chance to take a better look at the code and improve the documentation I am sure the maintainers and community members would be really happy.

Thanks for your answer @brodybits!

Yes, I would improve the documentation, but I feel still too noob about npm for being able to write something completely correct. My verbosity also wouldn’t help much in being clear :sweat_smile: But who knows, maybe in some months I’ll feel better about it!

Regarding my dependencies question…

Yes, I agree about your view on the mutually exclusive options.
What confused me was to have something just in devDependencies but not in dependencies, and felt wrong for a runtime dependency; but, yes, peedDependencies deputises for dependencies, even if with a looser approach: throwing a warn and delegating the user for installing it (kind of IoC). At least in NPM3 (that is another point of trying to choose the right place: retro-compatibility).

Am not yet satisfied with the manual install of the peer-dependency to be needed even when library_foo is the only dependency. That would have been one advantage of putting jQuery inside dependencies. But as I understand it could also lead to dependency duplicates (and break at runtime).

Dunno… maybe a postInstall script (in the library?) could take care of installing jQuery, if the dependency tree doesn’t have it. But also am not sure whether an operation like this would be more a responsibility of the package manager and would be a mistake trying to take care of it myself :thinking:

Still thinking about it…