fix: add npm view to transparent commands

[styfle]

• Related to Usage Error: This project is configured to use <pkgmgr> #157

[aduh95]

Docs: https://docs.npmjs.com/cli/v8/commands/npm-view

[ljharb]

it kind of seems like it'd be a more usable default to assume everything is transparent, and explicitly exclude the opaque ones.

[arcanis]

it kind of seems like it'd be a more usable default to assume everything is transparent, and explicitly exclude the opaque ones.

Allowing new commands isn't a major change, whereas forbidding some is.

Generally I'm not sure how I feel about this change. While on surface it makes some sense, in practice it bypasses any registry configuration configured for the project (which can lead to potential security problems if the information you get is obtained from the public one instead of the private one). To avoid that one should call yarn npm info instead, which leverages the Yarn configuration.

There's an argument that this won't matter in most cases, but there's also the opposite argument: the cases where this matter are more likely to make this easy mistake unless the system prevents them to do so.

[ljharb]

Allowing new commands isn't a major change, whereas forbidding some is.

that is a very good point. another alternative is disallowing all commands unless they're explicitly marked as opaque or transparent - then it'd always be semver-minor to mark a new command.

[aduh95]

@styfle What do you think of #158 (comment)? Going back to my idea of providing an ENV variable to disable the usage error would let user/CLI tools that know what they're doing bypass the Corepack check while avoiding to introduce errors for the most common case. (So you would do something like COREPACK_IGNORE_PACKAGE_JSON=1 npm view … or COREPACK_IGNORE_PACKAGE_JSON=1 npm install -g …)

[arcanis]

Fwiw I agree an environment variable would be reasonable.

Bikeshedding the name, I'd suggest COREPACK_ENABLE_STRICT_CHECK (or CLI_CHECK, maybe), which would default to 1; it would match other similar settings, avoid the double negation, and is less ambiguous than just referencing the package.json.

[styfle]

How about COREPACK_ENABLE_STRICT=1 to enable the error and COREPACK_ENABLE_STRICT=0 to disable it?

[aduh95]

@styfle do you still want this merged now that #167 has landed?

[styfle]

While on surface it makes some sense, in practice it bypasses any registry configuration configured for the project

Given this, I think we should close and rely on the new COREPACK_ENABLE_STRICT=0 env var.

I'm also curious if we can make -g or --global transparent by default but perhaps I'm overlooking something in those cases too.