Problem description

fetchLatestVersion() in playwright-cli.js hardcodes the update-check URL to https://registry.npmjs.org/${packageJson.name}/latest instead of respecting the user's configured npm registry.

Source file: https://github.com/microsoft/playwright-cli/blob/main/playwright-cli.js
Commit used for this report: b85c7a736bb473bf55b584e54a09ffa698d6d871.

Actual impact

The reporter notes that Microsoft internal users encounter this problem: enterprise policies may block access to this public URL, and the CLI's update check triggers Windows Security warnings. Even when an enterprise npm registry is configured, the CLI still accesses registry.npmjs.org directly.

Catching network errors only prevents the CLI from reporting an error; it does not prevent the outgoing request or the resulting security warning. No exact Windows Security warning text or screenshot was provided.

Steps to reproduce

1. In an enterprise-managed Windows environment, configure an enterprise npm registry through npm configuration or .npmrc, including @playwright:registry where applicable.
2. Ensure that neither NO_UPDATE_NOTIFIER nor CI is set and that the update-check cache is missing or older than one day.
3. Run a playwright-cli command to trigger the startup update check.
4. In an environment that blocks registry.npmjs.org, observe the outgoing public-registry request and any resulting Windows Security warning.

Expected behavior

The update check should respect the npm registry configuration applicable to @playwright/cli and comply with enterprise network policies. If a custom registry is unavailable, it should not fall back to public npmjs.

Suggested fix and acceptance criteria

• Resolve npm registry configuration correctly, considering environment variables, project/user/global .npmrc files, and scoped registries. Consider querying the version through npm to reuse its configuration and authentication logic.
• When an enterprise registry is configured, the update check must not send requests to registry.npmjs.org. Preserve the normal default behavior when no custom registry is configured.
• Preserve the existing approximately 1.5-second total lookup timeout, once-per-day cache check, and NO_UPDATE_NOTIFIER / CI opt-out behavior.
• Lookup failures, timeouts, or invalid responses must not affect the CLI's main functionality. If an npm subprocess is used, cover missing npm and Windows subprocess startup/termination behavior.
• Avoid leaking registry authentication information in output or logs.
• Use local test servers or mocks to cover default, custom, and scoped registries, as well as failure and timeout scenarios, without depending on a real enterprise network.

Temporary workaround

Set NO_UPDATE_NOTIFIER=1 to skip the current update check. This is not a long-term fix for respecting registry configuration.