Usage Error: This project is configured to use <pkgmgr>

[styfle]

One of the biggest problems I have today with Corepack is the Usage Error: This project is configured to use <pkgmgr>.

This happens when I run npm i -g vercel@latest in a project that is configured to use yarn or pnpm. This seems a little too strict because the global flag (-g) is not scoped to my current project.

Similarly, vercel dev will shell out to npm or npx and corepack being enabled could block it from working properly, even if the system has npm installed.

While I think the intention is good (catch accidental typos), I think this shouldn't be the default behavior because it is too restrictive. Perhaps making this strict mode be opt-in would help Corepack go stable (see #104).

[aduh95]

Or it could spawn a prompt: You are running a command the uses <pkgmng> in a directory configured to use <pkgmng>. Do you want to continue?.

[mehulkar]

I would also like to be able to run things like yarn --version or npm --version in a situation where corepack is enabled. This early UsageError prevents me from doing that. While debugging @nathanhammond and I noticed that config.json contains an allowlist of commands that are passed through:

corepack/sources/main.ts

Lines 46 to 55 in 312d9ea

	// If all leading segments match one of the patterns defined in the `transparent`
	// key, we tolerate calling this binary even if the local project isn't explicitly
	// configured for it, and we use the special default version if requested.
	let isTransparentCommand = false;
	for (const transparentPath of definition.transparent.commands) {
	if (transparentPath[0] === binaryName && transparentPath.slice(1).every((segment, index) => segment === args[index])) {
	isTransparentCommand = true;
	break;
	}
	}

I'm not sure if my case is a good use case for this config, but may be a good place to start?

[styfle]

Or it could spawn a prompt:

I think a prompt would be annoying and cause more problems because you need a way to pass --yes to corepack without it passing --yes to the underlying package manager. Maybe a warning would be sufficient, but the hard block is just too much of a breaking change.

The only thing that might be safe to hard block is <pkg> install. So perhaps the allowlist needs to be inverted to a denylist so most commands can be allowed.

[aduh95]

I think a prompt would be annoying and cause more problems because you need a way to pass --yes to corepack without it passing --yes to the underlying package manager.

Using an env variable would be more practical than a --yes flag IMO.

[styfle]

I think an env var would be good.

I also think corepack needs to be smart enough to ignore -g or --global flags automatically.