[RRFC] Reevaluate usage of update-notifier

[ruyadorno]

We've hit some bumps while using update-notifier in the last mile of npm@6 development and a couple of times it was brought up in conversations that we could possibly remove it for v7.

I'd like for us to discuss and come up with an actionable decision we can work on in time for v7.

Possible actions:

• Replace usage of update-notifier with a new system we can develop/control
• Help out with maintenance of update-notifier and steer it a the direction we want/need
• Do nothing; Just update to current versions of update-notifier and let it be
• Remove the feature completely

Related previous discussions:

• replace update-notifier cli#61
• [BUG] npm checks for new version when nobody asks for it cli#991
• deps: updates term-size to use signed binary cli#1053 (comment)

[ljharb]

A fourth option would be to remove it, and work like most npm modules do - only update when requested.

[Raynos]

I've found it useful to have all team members use the same version of node and npm when working on projects,

If some engineers respect and pay attentiont to update notifications and others don't then that leads to divergent versions in a team.

[travi]

I've found it useful to have all team members use the same version of node and npm

i follow a similar strategy with my team and even went as far as contributing a way to disable the notifier. i add this setting to the .npmrc file that is versioned in each project to remove the encouragement to get out of sync. this was especially valuable when lockfile thrashing was a bigger issue, but is still valuable.

i encourage my team to simply use the version installed with node, which we manage with nvm. nvm understandably doesn't yet support managing npm independently of node, but even if that were available to decouple us from the node version, i wouldnt want npm encouraging the team to get out of sync.

[ruyadorno]

A fourth option would be to remove it, and work like most npm modules do - only update when requested.

oh yeah of course 😅 added it to the list! thanks!

[isaacs]

I think "work like most npm modules do" is not really ideal, since npm is not most npm modules.

While it is not universally appreciated, this feature does provide a valuable feature for a lot of users who might not otherwise know that a bug or security issue has been fixed in the latest release. Over the last few years that it's been part of the CLI, we've seen a pretty significant reduction in bugs posted for things that are fixed in newer releases.

That being said, regardless of how we approach this, I'd like to see these ideas explored in an RFC:

• Using boxen means that we ship a binary with term-size that does ioctl stuff, and seems pretty unnecessary/bloated.
• We can streamline this a bit more effectively, and avoid hitting the registry when there's no other need to. (Checking for a new version when running npm ls seems odd, for example.)
• Perhaps it would be worth exploring something even more slick to remove the extra request entirely, by having the registry send the latest npm version in a header or something that npm-registry-fetch looks for and warns about? We could even do this conditionally based on the user-agent, so if we see a user-agent of yarn or pnpm we could advertise the latest version of that client instead.

[ljharb]

The last bullet point seems particularly interesting, since it would let private registries return a desired version as well.

[isaacs]

Oh, good point! I hadn't considered that, but yes, it would provide some interesting hooks to help people stay in sync rather than nudging them out of sync.

[travi]

it would provide some interesting hooks to help people stay in sync rather than nudging them out of sync

while that is interesting, i'm not sure the registry would be the best place to specify version either. at least in my case, we can vary across projects, but i imagine the registry doesn't know which project the requests are on behalf of (excuse my ignorance if this isn't true).

our variation is most often because of limitations of the host we are deploying to, since we try to use the same node version when developing. while we do stay up to date pretty well, some of the hosting we use only currently supports node v10, while other projects are able to leverage v12.

while i can buy the argument that we could just be consistent across all projects, regardless of node version, that still comes with additional complication. with the nvm approach mentioned above, along with using avn locally, we are better automated for actually staying in sync than a prompt can do. in addition, the nvm approach ensures that we are also using the same version on CI without additional configuration and maintenance.

[isaacs]

@travi In those cases, I assume you'd either set update-notifier = false in a .npmrc file, or just ignore the prompt anyway.

The registry does know what scope you're making requests for, but not which project specifically. So we could in theory make this an org-level config option server-side.

[travi]

In those cases, I assume you'd either set update-notifier = false in a .npmrc file

yep, that is what i do for our projects currently, but just wanted to provide context for that use case.

[ruyadorno]

Action item from the OpenRFC call:

• Open an actual RFC 🙃 so here were the main ideas we agreed upon:
  • Let's move on with @isaacs idea of having an user-agent header
  • Replace update-notifier with a module more suited to the specific needs of the npm cli
  • Would be desireable to provide more customization/flexibility to that prompt/msg since corporations and other proxy users could possibly extend on it

[ruyadorno]

folllowing up with #146