I thought I understood peerDependencies — but apparently I don’t.
- I have a compatibility-library, @elliottcable/bs-uchar.
- There are, effectively, two concurrent versions of that compat-lib. Let’s call them
- Each of those versions works with a very specific, mutually-exclusive subrange of an upstream project —
email@example.com works with
bs-platform@ ^4.0.0 || ^5.0.0; while
firstname.lastname@example.org works with
- My consumers are other libraries, using
bs-platform. They shouldn’t care about the version of
bs-uchar; it should silently upgrade to
v0.6.0if/when they upgrade their dependency on
- Downstream consurmers of those libraries shouldn’t ever hear of, or care about,
bs-uchar— it exists to smooth over a missing component of
tl;dr The end-goal is to tell my consumers to depend on
bs-uchar@*, and have npm resolve the version correctly according to what version of
bs-platform is installed.
Did I communicate all of that well? I can’t, for the life of me, figure out how to make this happen. I tried publishing
bs-uchar with a peer dependency on
bs-platform, expressing very lenient ranges — with the v6-shim-version peerDepending on
"bs-platform": ">=6.0.0", and the v4-shim-version peerDepending on
"bs-platform": "^4.0.0 || ^5.0.0". Unfortunately, when I
npm install 'bs-uchar@*' in a downstream project, I still get whatever the “latest” version of the compatibility-shim is; not the version that’s … actually compatible.
I tried the same thing with explicit dependencies, but that was worse — that meant downstream consumers got an extra copy of
bs-platform (which in this case is especially egregious; it Very Much Does Not play well with incorrect versions of itself scattered thru the dependency-tree.)
Help is very appreciated!