I'm submitting a ... (check one with "x")
[ ] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request => Please do not submit support request here
[x] process enhancement request
Current behavior
You're updating peerDependencies section of package.json file whenever there is a newer lib version. Well, this is not ideal at the very least - you should only be updating them if you KNOW that your lib won't work with previous version.
Expected behavior
Example:
rxjs is ^5.0.2. Let's say they had a bug which affected your package, and they fixed it in 5.0.3. Then you update the peerDependecy version - it makes senserxjs is ^5.0.2. You haven't updated it in a while, so rxjs is now at version 5.2.0. Your lib works fine with all versions between 5.0.2 and 5.2.0 so you leave the peerDependency specification as-is and delegate it to your library users to decide whether to update rxjs or not.What is the motivation / use case for changing the behavior?
You're misusing the peerDependencies section of package.json. It created unnecessary warnings during npm install for users that don't update rxjs, @angular/***, or zone.js libraries as often as you.
Please tell us about your environment:
macOS Sierra, npm 3.10.10
Table version: any
Angular version: any
Browser: not applicable
Language: not applicable
Here's a good example of managing peerDependencies
Thanks for much for the advise. You bring some good points and i'll def make those improvements!
Do you have any suggestions for suitable baselines of the peer deps?
About zone.js dependency - I don't think you really depend on it, so it can be removed altogether. With regards to rxjs you should find the earliest version that works as expected with your lib, and make it required.
Pretty much same logic goes for @angular/***, with a few exceptions. For example, I didn't see you using anything from @angular/compiler so you can just remove it. Plus, for @angular/platform-browser-dynamic - you only depend on it in DEV environment, so you should also remove it from peerDependencies list.
About all others - I'd suggest to go the rxjs path - find the minimal version of Angular that works with your lib, and make it the required "peerDependencies" version.
That's how I see it
Most helpful comment
About
zone.jsdependency - I don't think you really depend on it, so it can be removed altogether. With regards torxjsyou should find the earliest version that works as expected with your lib, and make it required.Pretty much same logic goes for
@angular/***, with a few exceptions. For example, I didn't see you using anything from@angular/compilerso you can just remove it. Plus, for@angular/platform-browser-dynamic- you only depend on it in DEV environment, so you should also remove it frompeerDependencieslist.About all others - I'd suggest to go the
rxjspath - find the minimal version of Angular that works with your lib, and make it the required "peerDependencies" version.That's how I see it