It allows packages to specify a wider version range for downstream users than a pinned version used in `devDependencies`. This is a common pattern if (say) your tests depend on certain less stable APIs but your published package only uses a smaller more stable subset. It’s especially useful if you want to support older semver-major versions, or even newer ones if you’re confident that the APIs you use will remain stable.
The example used in this post[1] on the Node blog is plugin systems, which is a very common expression of this pattern.
> Real question, not a challenge! I really don't understand this stuff, I've always found javascript dependency management very confusing.
I appreciate the clarification but it was clear to me the question was sincere FWIW! And yeah, a lot of this was hard for me to get a solid grasp on for quite a while. I think this tends to show up more in the JS ecosystem because semver was so eagerly adopted there, but I suspect it’s of similar benefit where semver is used and dev/prod dependencies is a proscribed distinction generally.
The example used in this post[1] on the Node blog is plugin systems, which is a very common expression of this pattern.
> Real question, not a challenge! I really don't understand this stuff, I've always found javascript dependency management very confusing.
I appreciate the clarification but it was clear to me the question was sincere FWIW! And yeah, a lot of this was hard for me to get a solid grasp on for quite a while. I think this tends to show up more in the JS ecosystem because semver was so eagerly adopted there, but I suspect it’s of similar benefit where semver is used and dev/prod dependencies is a proscribed distinction generally.
1: https://nodejs.org/es/blog/npm/peer-dependencies/