Drop in replacements

[Dwood15]

I apologize if this is a little disorganized/eclectic. Still working through how this all fits in with npm. Stripped out a large portion of the original doc I had written after hearing there is a WIP on an rfcs for deep aliasing, and didn't want to duplicate that effort.

This rfcs is about marking a package as being a viable candidate for both aliasing and/or deep-aliasing for another package.

Should this get accepted, being able to search for packages in lieu of another package, regardless of depth, should become pretty easy.

[nickserv]

This would be great for tracking packages that are renamed in major releases, especially now that packages like @babel/core and @material-ui/core are moving to organizations. It's confusing when you update old package names to their latest versions and don't realize that you're missing new versions with different names.

[styfle]

This would be amazing!

The web interface already shows scores for Popularity, Quality, and Maintenance...so adding the ability to compare "Alias Packages for X" in the web interface would be excellent when comparing these aliases 👌

Something like this (but instead of search on keyword, it would be alias):
https://www.npmjs.com/search?q=keywords:babel

[zkat]

After some discussion, we decided that the upcoming overrides API (RFC upcoming, /cc @aeschright) solves this problem without the added complication of registry-side changes.

[styfle]

Can you link to the RFC when it’s available so we can follow it?

[aeschright]

Here's the overrides RFC: #27

[Dwood15]

@zkat I feel like it's a mistake to not add registry changes that allow searching for overrides. /shrug

[styfle]

@zkat I read the overrides RFC in #27 and I don't believe that it will solve this particular use case. As @Dwood15 mentioned, this Drop In Replacements proposal is meant to be additional metadata in the registry for the purpose of searching. Can you explain how #27 will solve this use case?

[hutson]

The overrides API seems targeted at the consumer to empower them to replace packages in their tree.

However, it does not empower the package maintainer to communicate and encourage consumers to adopt replacement packages (in the case of renames, scope migrations, etc.)

👍 on re-opening this RFC please