Why do transparent commands use hardcoded versions?

[mrienstra]

And is there any way to override this behavior?

Current transparent commands and associated versions:
npm init 8.19.2
npx 8.19.2
pnpm init 7.12.2
pnpx 7.12.2
pnpm dlx 7.12.2
yarn dlx 3.2.3

I would have guessed that e.g. updating yarn to 3.2.4 using corepack prepare [email protected] --activate (or corepack prepare yarn@stable --activate) would result in yarn dlx using yarn 3.2.4, so I was a bit surprised to hear that this is not the case.

Edit: Work around, as per Corepack docs:

corepack [email protected] dlx create-astro

[aduh95]

I would have guessed that e.g. updating yarn to 3.2.4 using corepack prepare [email protected] --activate (or corepack prepare yarn@stable --activate) would result in yarn dlx using yarn 3.2.4, so I was a bit surprised to hear that this is not the case.

That sounds like a bug to me. Would you like to send a PR to fix that?

[merceyz]

Context for this issue: yarnpkg/berry#4850 (comment)

That sounds like a bug to me

Indeed, ideally it should only do that if the version it would have used doesn't support dlx.

[mrienstra]

Working on it!

[mrienstra]

sources/main.ts#L57-L59:

  const fallbackReference = isTransparentCommand
    ? definition.transparent.default ?? defaultVersion
    : defaultVersion;

When isTransparentCommand (when running a transparent command), definition.transparent.default (when available) will be chosen over defaultVersion. In my local testing, this seems to be the source of the bug.

E.g. if:
definition.transparent.default: 3.2.3+sha224.953c8233f7a92884eee2de69a1b92d1f2ec1655e66d08071ba9a02fa
defaultVersion: 3.2.4

(3.2.3 was the Yarn transparent.default version for Corepack 0.14.2)

Running yarn dlx create-astro will result in yarn dlx using Yarn 3.2.3.

This code gives the desired result:

  const fallbackReference = defaultVersion ?? definition.transparent.default;

Now, running yarn dlx create-astro will result in yarn dlx using Yarn 3.2.4.

I'm a little confused about why this was written the way it was in #19 (what problems were being solved), I'm guessing defaultVersion will almost always be set, so after my proposed fix, definition.transparent.default will rarely be used.

Maybe the intended behavior was:

1. If user has changed the packageManager version via e.g. corepack prepare yarn@stable --activate, use that version.
2. Otherwise, use the transparent.default version, if set (which it is for Yarn).
3. Otherwise, use the default version.

Oh, and only yarn has a value for transparent.default, so presumably this change will only alter the behavior of yarn dlx -- if config.json is otherwise left as-is, yarn dlx will use 1.22.19 instead of 3.2.4.

What's the thinking behind defaulting to Yarn v1 (classic)? Given that Yarn v2 was released over 2.5 years ago, and Yarn v1 entered maintenance mode at the same time. Granted, from npm's perspective, yarn@latest is 1.22.19, so maybe it's for consistency with that? corepack prepare yarn@stable --activate takes you all the way from 1.22.19 to 3.2.4.