Honor the declared package manager

[Toflar]

The installer previously preferred an available Yarn or pnpm executable even when the consuming project declared npm through e.g. "packageManager": "npm@11.6.0" in package.json.

The installer now honors supported packageManager declarations for npm, Yarn, and pnpm. When no supported manager is declared, the existing lockfile and executable detection remains in place.

[Toflar]

Failing test looks unrelated, I think... 😇

[smnandre]

@Kocal any time to have a quick look here by chance? I'd trust you more than myself here as always :)

[smnandre]

@Toflar thank you! I'm asking for advice to my colleague (if he has time), it has nothing to do with your PR, and everything to do with my less-than-average knowledge about JS package managers :)

[Kocal]

I didn't check, but I'm quite sure (or fully wrong), that the code does not really execute the exact package manager mentioned in the packageManager field.

With Corepack (which is now deprecated/removed) or latest versions of pnpm, which both respect the packageManager field, there is a kind of magic that automatically configure the exact package manager (and its exact version) for your project, that you can run in your shell without any issue.

Here, I think that if you have pnpm version X globally installed and pnpm version Y in packageManager field, then your patch will execute pnpm version X instead of the version Y 🤔

But I may be wrong

[Copilot]

🟡 Changes recommended

Modern Yarn declarations currently select an incompatible Yarn Classic installation command, and fallback coverage is lost.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Honors the consuming project’s declared npm, Yarn, or pnpm package manager before existing fallback detection.

Changes:

• Detects packageManager from the current project.
• Validates the selected manager and updates help text.
• Adds isolated CLI coverage for declared npm.

File summaries

File	Description
bin/playwright-install	Adds declared package-manager detection.
tests/Integration/Installer/PlaywrightInstallCliTest.php	Adds npm-selection coverage and isolated executables.

Review details

• Files reviewed: 1/2 changed files
• Comments generated: 1
• Review effort level: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[Toflar]

You’re right, this selects the package manager name but doesn’t enforce the declared version.

My original issue was that GitHub CI has Yarn Classic installed, so the installer selected Yarn even though our project declares npm@11.6.0. The declaration now takes precedence over fallback detection and the version isn't that important in that case because it would select the right one.

However, I have also introduced support for an explicit executable override now:

vendor/bin/playwright-install --package-manager-bin=/path/to/npm --browsers

That keeps the usual installer checks and comfortable auto-detection while also giving users maximum flexibility to define a different binary locally/in CI. Version management explicitly stays with the environment.

Better?

[Kocal]

By curiosity, I looked at how Vite is able to detect the package manager (to install deps and run the dev-server when creating a project), and they simply use the npm_config_user_agent env var (automatically defined by npm) and their function pkgFromUserAgent.

Given how Vite is ultra popular, we can say that this solution is battle-tested.

To me, we can safely rely on it, and remove getExplicitPackageManager(), getDeclaredPackageManager() and even detectAvailablePackageManager().

[Toflar]

Thanks for looking into this! One difference is that create-vite is typically launched through a package manager, whereas our vendor/bin/playwright-install is run directly or through Composer. In that case, npm_config_user_agent is likely not set.

Vite handles that by falling back to npm. We could adopt the same approach, but it would mean defaulting to npm even when the project declares pnpm or Yarn in package.json. Not sure we want that?

That would solve my CI issue too, since the problem was selecting the preinstalled Yarn Classic instead of npm. But just "by chance" because in my case I have npm. Are we happy with “use the invoking package manager when known, otherwise npm” as the intended behaviour here? If so, we can simplify the detection considerably. Otherwise, it's probably more powerful the way it is now?