Warn about the dangers of Peer Dependencies

[alexanderson1993]

modern-guide-to-packaging-js-library/README.md

Line 85 in e1788d7

You should also add the framework to your library's `package.json`'s [peer dependencies](#set-your-peerdependencies) to indicate to developers that you rely on that framework.

I found there were a lot of libraries that had peer dependency pinned to React 17, but the React 18 upgrade was still perfectly compatible. It caused all kinds of unnecessary warnings when attempting to install the library with React 18.

It's nuanced and might be different for every library, but a better approach might be to have the peer dependency have a minimum supported version, but support all versions after that. If a library's breaking changes will affect your library, you can pin the peer dependency to the last working version of the dependency, and then when you release an upgrade to your library that is compatible, you can remove the pin and possibly bump the minimum supported version.

From the Node.js blog:

One piece of advice: peer dependency requirements, unlike those for regular dependencies, should be lenient. You should not lock your peer dependencies down to specific patch versions. It would be really annoying if one Chai plugin peer-depended on Chai 1.4.1, while another depended on Chai 1.5.0, simply because the authors were lazy and didn't spend the time figuring out the actual minimum version of Chai they are compatible with.
The best way to determine what your peer dependency requirements should be is to actually follow semver. Assume that only changes in the host package's major version will break your plugin. Thus, if you've worked with every 1.x version of the host package, use "~1.0" or "1.x" to express this. If you depend on features introduced in 1.5.2, use ">= 1.5.2 < 2".

[frehner]

Awesome, thank you! I’ll get this updated

[frehner]

Ok, in reviewing this, I've been thinking about the balance (as a library author) of indicating that you have explicitly tested your library with [new version] vs warning devs that you maybe haven't had the chance / time to do so yet.

I think for now I'm going to leave it as is, but maybe there's a concise way to talk about "what version of the peer dependency do you want to indicate you support."