You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This thread aims to discuss the "global packages" scenario. For example, the pmm version of pnpx --version is currently forbidden if run within a Yarn project, even though it's supposed to run within a standalone context that might not be related.
My opinion about this is that the current behaviour isn't a problem. Justifications:
Under the current model, npm is unmodified, so users would be able to use npm install -g or npx regardless of the package manager for the current project. This reason alone makes this problem non-blocking, although it's an interesting discussion nonetheless.
Using pnpx on a Yarn project (or even npx, even if not applicable because of the first point) may be dangerous. For example, we are looking to make yarn dlx (the Yarn equivalent) persist some parts of the local configuration (for example custom registries). Using a different package manager for the "x" command would lead to installs being made based on the incorrect configuration, so packages would be installed from the wrong registry.
The initial point that "projects decide which package managers they are meant to be used with" doesn't apply here, because global commands aren't cloning them - they are installing them, as any other command. For this reason, requiring to use yarn dlx on Yarn projects (rather than allowing pnpx) won't have negative effects.
Activity
arcanis commentedon Aug 11, 2020
My opinion about this is that the current behaviour isn't a problem. Justifications:
Under the current model,
npmis unmodified, so users would be able to usenpm install -gornpxregardless of the package manager for the current project. This reason alone makes this problem non-blocking, although it's an interesting discussion nonetheless.Using
pnpxon a Yarn project (or evennpx, even if not applicable because of the first point) may be dangerous. For example, we are looking to makeyarn dlx(the Yarn equivalent) persist some parts of the local configuration (for example custom registries). Using a different package manager for the "x" command would lead to installs being made based on the incorrect configuration, so packages would be installed from the wrong registry.The initial point that "projects decide which package managers they are meant to be used with" doesn't apply here, because global commands aren't cloning them - they are installing them, as any other command. For this reason, requiring to use
yarn dlxon Yarn projects (rather than allowingpnpx) won't have negative effects.