Always consult npm_config_user_agent first#95879
Open
eps1lon wants to merge 1 commit into
Open
Conversation
Contributor
Tests PassedCommit: a37dc69 |
Contributor
Stats from current PR✅ No significant changes detected📊 All Metrics📖 Metrics GlossaryDev Server Metrics:
Build Metrics:
Change Thresholds:
⚡ Dev Server
📦 Dev Server (Webpack) (Legacy)📦 Dev Server (Webpack)
⚡ Production Builds
📦 Production Builds (Webpack) (Legacy)📦 Production Builds (Webpack)
📦 Bundle SizesBundle Sizes⚡ TurbopackClient Main Bundles
Server Middleware
Build DetailsBuild Manifests
📦 WebpackClient Main Bundles
Polyfills
Pages
Server Edge SSR
Middleware
Build DetailsBuild Manifests
Build Cache
🔄 Shared (bundler-independent)Runtimes
📝 Changed Files (2 files)Files with changes:
View diffspages-api-tu..ntime.dev.jsDiff too large to display pages-turbo...ntime.dev.jsDiff too large to display 📎 Tarball URLCommit: a37dc69 |
eps1lon
changed the title
npm_config_user_agent first
eps1lon
changed the title
npm_config_user_agent firstnpm_config_user_agent first
eps1lon
marked this pull request as ready for review
July 17, 2026 07:10
The `getPkgManager` helpers previously consulted the filesystem first: the `packages/next` variant checked for lockfiles in the base directory and then probed `yarn --version` / `pnpm --version` via `execSync`, while the `packages/next-codemod` variant walked up parent directories with `find-up` and never read the user agent at all. This change makes both helpers check the `npm_config_user_agent` environment variable first. The variable is set by the package manager that invoked the process, so when present it is both the cheapest and the most direct signal, avoiding filesystem access and subprocess spawns entirely. `create-next-app` already used this user-agent-first approach and is unchanged. The check order is now consistent across all three implementations: yarn, pnpm, bun, npm for the user agent (the `packages/next` variant has no `bun` in its `PackageManager` type and falls through to lockfile detection there), and the same order for the codemod's lockfile walk, which previously prioritized `package-lock.json`. Because the invoking package manager now takes precedence over lockfile inference, running `npx next ...` or `npx @next/codemod ...` inside a pnpm or yarn app is now detected as npm. Use `pnpx` (or `pnpm dlx`) and `yarn dlx` instead so the detected package manager matches the project.
eps1lon
force-pushed
the
sebbie/getpkgmanager-npm-user-agent-e82f97
branch
from
July 17, 2026 07:33
e6d570a to
a37dc69
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
getPkgManagerhelpers previously consulted the filesystem first for files hinting at the used package manager. Only if none were found did we checkprocess.env.npm_config_user_agentand then shelled out to testing which package manager is available.This change makes all helpers check the
npm_config_user_agentenvironment variable first. The variable is set by the package manager that invoked the process, so when present it is both the cheapest and the most direct signal, avoiding filesystem access and subprocess spawns entirely.create-next-appalready used this user-agent-first approach and is unchanged.The check order is now consistent across all three implementations: yarn, pnpm, bun, npm for the user agent (the
packages/nextvariant has nobunin itsPackageManagertype and falls through to lockfile detection there), and the same order for the codemod's lockfile walk, which previously prioritizedpackage-lock.json.Because the invoking package manager now takes precedence over lockfile inference, running
npx next ...ornpx @next/codemod ...inside a pnpm or yarn app is now detected as npm. Usepnpx(orpnpm dlx) andyarn dlxinstead so the detected package manager matches the project.