3 ms·

Yeah - this peer dependency thing always makes issues, when I try to upgrade a big Ionic project... Peer dependencies added more problems than they solved in m

Yeah - this peer dependency thing always makes issues, when I try to upgrade a big Ionic project... Peer dependencies added more problems than they solved in my eyes... Most peer dependencies warnings come because some maintainer forgot to update the package.json and not really because two packages don't work with each other...

eyelidlessness 5y ago
The point of peer dependencies is to allow users more flexibility in choosing the specific version of the dependency. It’s not intended to specify any kind of conflict between the packages, it’s effectively BYO sub-dependency.
- jrochkind1 5y ago
  regular traditional dependencies can already be specified as a range, yes? Any range the specifier wants (and can legitimately work with), yes? What is it about peer dependencies that give the host more flexibility in choosing the specific version? Real question, not a challenge! I really don't understand this stuff, I've always found javascript dependency management very confusing.
  - chain-- 5y ago
    I could be wrong but I think it is used to alert you when you have incompatible dependencies. For example if you have a dependency with a peerDependency `something: 2.x.x` and you currently have `something: 1.0.0` installed as a direct dependency, it will fail rather than allowing multiple versions to be run.
  - eyelidlessness 5y ago
    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. 1: https://nodejs.org/es/blog/npm/peer-dependencies/ https://nodejs.org/es/blog/npm/peer-dependencies/

eyelidlessness 5y ago

The point of peer dependencies is to allow users more flexibility in choosing the specific version of the dependency. It’s not intended to specify any kind of conflict between the packages, it’s effectively BYO sub-dependency.

jrochkind1 5y ago
regular traditional dependencies can already be specified as a range, yes? Any range the specifier wants (and can legitimately work with), yes? What is it about peer dependencies that give the host more flexibility in choosing the specific version? Real question, not a challenge! I really don't understand this stuff, I've always found javascript dependency management very confusing.
- chain-- 5y ago
  I could be wrong but I think it is used to alert you when you have incompatible dependencies. For example if you have a dependency with a peerDependency `something: 2.x.x` and you currently have `something: 1.0.0` installed as a direct dependency, it will fail rather than allowing multiple versions to be run.
- eyelidlessness 5y ago
  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. 1: https://nodejs.org/es/blog/npm/peer-dependencies/ https://nodejs.org/es/blog/npm/peer-dependencies/