Provide a package.json field dedicated to peerDependencies

[Lcfvs]

Hi,

Since V7 supports --save-peer, I think it would be paired with a related feature and implications:

• We need to be able to recommand that install mode by default, maybe by a specific field in the package.json
• We also need to have a related copy to clipboard install instead of npm install xxx, on the NPM website, if that field is present.
• Optionally, notify, on install, if a module flagged as peer is installed but not as peer.

What do you think about, it, please?

[ljharb]

So let’s say the project with this field is eslint, which should generally be a peer dep. what about the end users who need to install it as a dev dep? Let’s say it’s react - what about the end users who need to install it as a dep?

[Lcfvs]

@ljharb That's why I'm speaking about a recommandation and a notification, the goal isn't to enforce it. ;)

[ljharb]

What I’m asking is, what happens when the common case - beginners needing to add it as a direct dep - runs into that recommendation?

The cases where it needs to be added as a peer are the rarity, since they only apply to package authors, which is on average a more experienced group than package consumers.

[Lcfvs]

Interesting question... because even if you're right about the beginners, they might not understand some bugs caused by different instances of a common dependency where they should have an unique.

This discuss can maybe weigh these 2 (or more) problems. :)

[Lcfvs]

In any case, I think useful to have something to indicate that recommanded behavior, for these experimented users, without the need to search if it's needed.

Maybe flagged by something like a peer icon that switches between npm install / npm install --save-peer if the package.json contains a field like "peer": true

[ljharb]

Anything that automatically uses --save-peer will break for the majority case, regular users. The only time things like this should be saved as a peer is in a package you plan to publish - an app should only have them as deps or dev deps, and wouldn't have any peer deps at all.

[Lcfvs]

Yeah, that why my latest message (about the peer icon).

By default, it doesn't changes the current behavior, it only provides a visible tip for the devs that can need it as peer... and only shows the alternative command when the peer icon is clicked.

[peer "unchecked", default] npm i xxx
[peer "checked"] npm i --save-peer xxx

It isn't a good compromise?

[Lcfvs]

That icon presence distincts a module which should generally be a peer dep.

Actually, I don't think we have something distinctive like that where it's a useful information.

[ljharb]

Sure, that seems like it wouldn't cause confusion, especially if the website had a nice explanation of when it's appropriate to save as a peer or not. However, whether something should be a peer or not isn't always something the author of the package has the context to suggest - I don't think a package.json field would make sense for every case.

[Lcfvs]

I almost approve, but the package author has the context to know if it can be a source of problems.

I think there is 2 package types: projects creating some specific references (constructors, prototypes, etc.) that can be generally compared against multiple dependencies/project or not.

[MylesBorins]

Hey @npm/cli any thoughts on this?

[isaacs]

So, this is a bit like --prefer-global, and has many of the same hazards.

In practice, paradoxically, the package author is generally less able to identify how something needs to be installed than the package consumer. There are many cases where react in fact must be installed as a dep rather than a peer dep, even cases where it must be duplicated. Consider: using react@16 for your react-native application, and react@17 for your website. Two separate apps, maybe workspaces in the same top-level project mostly sharing a dependency tree. Throw in ink for a CLI app, and you might have three versions of react, without any conflict.

The assumption that something will always be a peer dep is a big part of why standard is in such a weird state now with the latest version bumps to eslint, when installed with npm v7. If we follow all the stated dependency contracts, there are cases where standard simply cannot work, because of how eslint loads its configuration files. I'm told this will be fixed in the next version of eslint, but it's still an example of the problem caused by a framework developer's assumption that their framework will always be a top-level singleton, in a world where that cannot (and should not) be guaranteed.

If you think that your package should usually or typically be a peer dep, that's fine. Put it in your documentation. Experienced users will know when they are an exception. However, if we post a warning about it whenever we see react as a regular dep, that's going to make extra noise that could easily guide people in the wrong direction.

If you must insist that your package is a singleton in a given run environment, there are ways to do this. Just do what React and others do: set a global value, and check for it. Throw an informative error if some other instance already set it. Doing this at the package manager level is a bit too presumptuous, and carries much more hazard than one might guess.

[Lcfvs]

Thanks for your feelings.

The idea isn't to enforce anything, just annoyed be the "Put it in your documentation." for something related to the install process which is common on many projects.

I didn't deny the doc role for that but the docs aren't always written in the same manner, then the users must search about it... that's the point I dislike.

[Lcfvs]

It's ok, I finally opted for a specific badge I created... since by convention, the badges are always used on top of a readme.

Feel free to use it too. :)

https://github.com/Lcfvs/library-peer

PS: Sorry for the disturbing