`npx` output includes update message

[ljharb]

If I want to be able to use npx foo in CI, and in automated scripts, I have to know that the output will only be from foo.

However, I occasionally get output like this:

   ╭─────────────────────────────────────╮
   │                                     │
   │   Update available 5.2.0 → 9.3.2    │
   │     Run npm i -g npx to update      │
   │                                     │
   ╰─────────────────────────────────────╯

This is also problematic with npm, but that CLI is typically verbose, so nobody tends to rely on it.

Do I have to always include --silent (I don't get the update output predictably, so I can't really check if this even works), or can npx instead be changed to not add this disruptive (and unnecessary; if i want to update, i would have done so) output?

[zkat]

https://www.npmjs.com/package/update-notifier#user-settings

Users of your module have the ability to opt-out of the update notifier by changing the optOut property to true in ~/.config/configstore/update-notifier-[your-module-name].json. The path is available in notifier.config.path

Users can also opt-out by setting the environment variable NO_UPDATE_NOTIFIER with any value or by using the --no-update-notifier flag on a per run basis.

I believe this would be sufficient for your needs, and I would rather keep the notifier. Is this good enough to get this issue closed?

[ljharb]

I suppose I can set NO_UPDATE_NOTIFIER (that config file path is unreasonably long/deep, i don't even have a ~/.config dir), but I think the updater is not actually providing value; npm is almost always global, so there's no package.json to make it easy to know an upgrade is needed, and the updater is fine - but npx won't be, so the updater is likely to cause more problems than it's solving.

npx is solely a runner; I'm not sure why it's npx's business what version I'm using :-( It seems very paternalistic/condescending.

[zkat]

@ljharb experience has taught me that it is tremendously troublesome to have a wide range of users using a wide range of different versions. It is definitely my intention to let users know when new versions pop up, since new versions often have bugfixes and missing features. Without regular updates, you get stuff like, well... #97 😁 In short, it has a tangible effect on the ease of maintainability, since this package is basically just maintained by 2-3 people who are also spending a lot of time on other tools. :\

I'm sorry about the impression it's giving. It's definitely not intended to be paternalistic/condescending -- the vast majority of feedback we've received about the update notifier has been overwhelmingly positive (modulo https://github.com/yeoman/update-notifier/issues/67, which I hope will be resolved at some point, which is the other most common comment I get about it). That's the feedback I've worked off of, and I value the input, but also think it would be very disappointing to all those users who celebrated the notifier if it was taken away based on one person's comment? (not to mention, inconvenient for me due to aforementioned maintainability concerns).

It's worth noting, by the way, that npx only checks for updates when it is going to run an npm installation. So, if you have your packages installed as devDependencies, and you're running npx in a script, the update-notifier package won't even be loaded. So that's another thing you can take into account as far as bypassing this message.

[ljharb]

Ah, that does explain why it's been so unpredictable in its appearance.

Given that check, the use case where it's in a package.json will undoubtedly have the package used as a dev dep - so it shouldn't appear. Needless to say I'm still at the CLI experimentation stage :-)

Thanks for explaining!