Allow disable self-update checking globally

[Mister-Hope]

When running this package, it ALWAYES want to check whether it's latest before doing anything I want.

All I want is to focus on my current job.

So it would be great if:

• We can disable this feature globally
• We can choose to let it check later (I mean do the current job while checking the version, and add a hint msg after all the job is done)
• Respect --registry option

I would want all of them, but one of them is enough for me.

Motivation

The biggest problem for me is that the official registry is often timeout (in mainland china). While the package choose to check self update at start up, it will get stuck and I have to give a lot of retries even I specific a registry mirror, and I am not finding clear guideline on README (I am not 100% sure if there is an option, but I can say that I read that long README for 5 min and do not find one)

[raineorshine]

Hi, thanks for reporting.

It looks like update-notifier, which npm-check-update uses for self-updates, does not have a registry option that can be passed explicitly. However it is supposed to respect the registry option in your .npmrc. Do you have the registry set in your .npmrc?

If that doesn't work, I can add an environment variable to disable update-notifier globally.

[raineorshine]

If would be annoying for any project which has an existing .npmrc. I choose to create alias with common commands with extra --registy xxxx. So I don't think adding a registry field to .npmrc is a good option, the others might not need this.

In this case, maybe there is a fork of update-notifier that adds a registry option. Then we could forward the --registry option from npm-check-updates.

Also, I think that

We can choose to let it check later (I mean do the current job while checking the version, and add a hint msg after all the job is done)

This should be good. I don't think it is urgent to check update first while blocking any process.

From my understanding, update-notifier attempts to be as unobtrusive as possible, and does not block the process.

From their documentation:

Whenever you initiate the update notifier and it's not within the interval threshold, it will asynchronously check with npm in the background for available updates, then persist the result. The next time the notifier is initiated, the result will be loaded into the .update property. This prevents any impact on your package startup performance. The update check is done in a unref'ed child process. This means that if you call process.exit, the check will still be performed in its own process.

The first time the user runs your app, it will check for an update, and even if an update is available, it will wait the specified updateCheckInterval before notifying the user. This is done to not be annoying to the user, but might surprise you as an implementer if you're testing whether it works. Check out example.js to quickly test out update-notifier and see how you can test that it works in your app.

I would say that modifying/improving the update-notifier behavior is outside the scope of npm-check-updates. If you think it's not configured correctly in npm-check-updates please open a PR, otherwise I recommend opening an issue with update-notifier.

However, I am open to adding an environment variable that disabled update-notifier in npm-check-updates. I can add it when I have time, or you can open a PR to expedite the process.

[Mister-Hope]

From my understanding, update-notifier attempts to be as unobtrusive as possible, and does not block the process

I am sure that ncu -u can be blocked for minutes when the connection to official register is unstable before showing any progress bar, So it seems that at least your package behavior is not what as you announced that self update does not block the process.

I suggest we should focus on this first.

I don't hate the self update logic. I just hate that it came first and block the whole process, parrall or performing it at last all sounds good to me, This is expected for me and I believe this should be the best options for most users.

[Mister-Hope]

I would say that modifying/improving the update-notifier behavior is outside the scope of npm-check-updates. 

I understand that. So if customizing the self update registry is not flexible, then we can turn to the two other options.

[Mister-Hope]

If you are sure that the updatepackage won't lock the process that maybe we should search for things that is blocking the process when in a weak network environment.

I'm expecting the progress bar can be showed immediately

[raineorshine]

Yes, that doesn't sound right to me either. The documentation of update-notifier clearly states that it will check in the background and then notify on the next run.