Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add check-installed-peers rfc #386

Closed
wants to merge 1 commit into from
Closed

Add check-installed-peers rfc #386

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
49 changes: 49 additions & 0 deletions accepted/0000-check-installed-peers.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
# Add `check-installed` option to `peerDependenciesMeta`

## Summary

Currently `peerDependenciesMeta` (as far as I know) only adds the ability to basically turn off peer dependency warnings for your peer. I would like to add the ability to mark a dependency that may or not be installed (`optional` but that terminology is already used) but who's version should be checked if it is installed.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems to me like it should be the default behavior. An optional peer dep will likely be try/catch required. If the wrong version exists, the program will happily use it, and perhaps break in terrifyingly silent ways.

I can't think of any use case where the package exists, the version is incompatible, and that's desirable.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems to me like it should be the default behavior. An optional peer dep will likely be try/catch required. If the wrong version exists, the program will happily use it, and perhaps break in terrifyingly silent ways.

I can't think of any use case where the package exists, the version is incompatible, and that's desirable.

Yes I completely agree. It would be much easier and better to modify existing behaviour but I was trying to avoid breaking what has already been implemented.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fwiw what this RFC describes is how Yarn implements it. That npm has a slightly different behavior wasn't intended and mostly just an oversight when I ported it. Seems a good idea to align.


## Motivation

I have encountered several situations where a package can have optional peers depending on the use case of the package. If the peer is installed though it will be important to have the correct version. Examples include:

* A config package that contains configs for various libraries. If the `eslint` config is used by the consuming package then the `eslint` peer needs to be installed but must be a minimum version for the config.
* An async package that provides promise based and observable based versions of it's functions. If the PRomise based versions are used `rxjs` is not required. If the observable versions are used then the `rxjs` peer should be installed and the version should be within the specified range.

## Detailed Explanation

I expect that an additional config option would be added to `peerDependenciesMeta`:

```json
{
"peerDependencies": {
"rxjs": "^6.0.0"
},
"peerDependenciesMeta": {
"rxjs": {
"check-installed": true
}
}
}
```
(I am now married to the `check-installed` name but can't currently think of anything better)

If `check-installed` is specified then no warning would be printed if the peer is not installed. If it is installed warnings about incompatible versions would be printed.

## Rationale and Alternatives

* **do not specify a peer** - Means that documentation must be relied on and if a new version of the dependency is installed that needs a different version of the peer there will be no warnings and the app will break.
* **specify the peer normally** - means that all consumers of your package will have to install a dependency that they don't need to get rid of the peer warning
* **specify an optional peer** - as far as I can see this is little different than the first option.

## Implementation

To be completed

## Prior Art

The only prior art I can think of is the existing `peerDependenciesMeta` configuration option that has already been discussed.

## Unresolved Questions and Bikeshedding