Why do Yarn "transparent" commands use hardcoded versions? #202

Activity

1. aduh95 commented on Oct 29, 2022

   

   aduh95

   on Oct 29, 2022

   Last edited by aduh95

   Contributor

   More actions

   I would have guessed that e.g. updating yarn to 3.2.4 using corepack prepare yarn@3.2.4 --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?

   👍React with 👍1Reacted by Michael Rienstra
2. merceyz commented on Oct 29, 2022

   

   merceyz

   on Oct 29, 2022

   Member

   More actions

   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.
3. mrienstra commented on Oct 29, 2022

   

   mrienstra

   on Oct 29, 2022

   Author

   More actions

   Working on it!
4. mrienstra commented on Oct 31, 2022

   

   mrienstra

   on Oct 31, 2022

   Author

   More actions

   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.
5. aduh95

   changed the title [-]Why do `transparent` commands use hardcoded versions?[/-] [+]Why do Yarn "transparent" commands use hardcoded versions?[/+] on Feb 7, 2025
6. aduh95

   marked yarn init ignores global default version #589 as a duplicate of this issue on Feb 12, 2025