Stop Next Hot Reloading from uncontrollably polling npm registry #81004

[cefn]

Goals

Violating POLA in my view, next hits the npm registry whenever a local server runs in dev mode with webpack hot reloading.

The offending code is at

next.js/packages/next/src/server/dev/hot-reloader-webpack.ts

Line 210 in b91297d

res = await fetch('https://registry.npmjs.org/-/package/next/dist-tags')

I would like it to be possible for team members using my next server not to trigger network security violations from uncontrolled HTTP requests unexpectedly emanating from their machines whenever they run next dev

Non-Goals

No response

Background

Violating POLA in my view, next hits the npm registry whenever a local server runs in dev mode with webpack hot reloading.

It does this without any reference to the project's chosen registry, and is commented explicitly as an intervention that bypasses the user's choice and configuration of package tooling.

The next server making unrequested outbound network requests when apparently just running a local server prompted time dedicated to network security investigation which I would rather have avoided. Use of public registries for malware telemetry is common, so this behaviour will likely trigger alerts in enterprises.

It appears to be a bonus feature for some kind of console output integrated with hot reloading that could output the latest available next version. Blending these features violates separation of concerns in my view. I would strongly prefer hot reloading to focus on its job and not try to upsell me to newer next versions, especially if this involves an undocumented round-trip to a public server.

I would not expect this to happen without my explicit choice or consent. Having this as the default we should definitely be able to prevent it from happening with some form of environment variable or control, but the code paths I can see provide no mechanism for the feature to be disabled.

Proposal

One potential approach would be to respect the NEXT_TELEMETRY_DISABLED=1 configuration. An alternative is to create a separate environment variable scoped to be able to turn off the feature. I can see that versionInfo being null is a valid configuration, and the fact my strict network controls prevent this outbound request doesn't block the core hot reloading feature. For this reason I feel it can be simply removed without cost, or scoped to specific code paths such as upgrade codemods.

Preferably this behaviour would be completely removed, or opt-in with an environment variable to turn it on instead. If this level of support is not justified, perhaps the feature is not justified.