[Bug?]: `yarn set version` sets `yarnPath` in `.yarnrc.yml` when using corepack to manage versions #4063

qcn · 2022-02-02T15:57:54Z

Self-service

I'd be willing to implement a fix

Describe the bug

Corepack is now the recommended way to install/manage Yarn versions and according to the docs it

lets you use different package manager versions across multiple projects without having to check-in the Yarn binary anymore

However, running yarn set version to update Yarn sets yarnPath in the .yarnrc.yml file, so if I check in the other changes made by set version without checking in the binary, trying to run Yarn errors if the binary isn't there (eg. on a fresh checkout).

Given that the documentation says I don't need to check in the Yarn binary, I expect that using the CLI to lock my package manager version in the documented way will not make any changes that would require the binary to be in that location.

To reproduce

Run corepack enable
Create a new directory with a package.json file containing only:

{ "packageManager": "[email protected]" }

Run yarn -v and observe that it succeeds - corepack is handling it.
Run ls -a and observe that the package.json file is the only file in this directory.
Run yarn set version 3.1.1.
Run rm .yarn/releases/yarn-3.1.1.cjs
Run yarn -v and observe the error:
Internal Error: The "yarn-path" option has been set, but the specified location doesn't exist.
Run yarn config unset yarnPath
Run yarn -v and observe that it succeeds - corepack is handling it again now that the change yarn set version made to yarn config has been reverted.

Environment

System:
    OS: macOS 11.6.1
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
  Binaries:
    Node: 14.19.0 - /private/var/folders/n7/8y3h45rn5jq9lrd744w_m7xh0000gn/T/xfs-8cbd9b83/node
    Yarn: 3.1.1 - /private/var/folders/n7/8y3h45rn5jq9lrd744w_m7xh0000gn/T/xfs-8cbd9b83/yarn
    npm: 6.14.16 - ~/.nvm/versions/node/v14.19.0/bin/npm

Additional context

No response

The text was updated successfully, but these errors were encountered:

merceyz · 2022-02-02T16:00:17Z

This is on purpose, the fact that the system running the command has Corepack enabled doesn't mean another system does. To make sure systems without Corepack use the correct version it sets both.

qcn · 2022-02-02T23:34:53Z

This is on purpose, the fact that the system running the command has Corepack enabled doesn't mean another system does. To make sure systems without Corepack use the correct version it sets both.

My understanding is that with this configuration Corepack won't be used, as it will prefer the yarn path. So in that case, isn't it misleading to suggest that Corepack provides the benefit of not having to check in the binary, given that the same page also directs you to run yarn set version "any time you want to update" and commit the results?

arcanis · 2022-02-02T23:50:45Z

Yes and no. Updating the binary in the repo, is temporary, until Corepack gets available in all LTS releases. I think for Yarn 4 we'll consider only updating the package.json.

qcn · 2022-02-02T23:54:19Z

Yes and no. Updating the binary in the repo, is temporary, until Corepack gets available in all LTS releases. I think for Yarn 4 we'll consider only updating the package.json.

That makes sense, thank you for considering that! (I got very excited when I updated Node and saw Corepack in the release notes, so I jumped straight to trying it on our project.) I'll continue to use our current setup until Yarn 4 in that case.

yarnbot · 2022-03-05T00:14:37Z

Hi! 👋

This issue looks stale, and doesn't feature the reproducible label - which implies that you didn't provide a working reproduction using Sherlock. As a result, it'll be closed in a few days unless a maintainer explicitly vouches for it or you edit your first post to include a formal reproduction (you can use the playground for that).

Note that we require Sherlock reproductions for long-lived issues (rather than standalone git repositories or similar) because we're a small team. Sherlock gives us the ability to check which bugs are still affecting the master branch at any given point, and decreases the amount of code we need to run on our own machines (thus leading to faster bug resolutions). It helps us help you! 😃

If you absolutely cannot reproduce a bug on Sherlock (for example because it's a Windows-only issue), a maintainer will have to manually add the upholded label. Thanks for helping us triaging our repository! 🌟

[Version 16.20.0 of Node.js][Node.js changelog 16.20.0], released on 2023-03-29, ships with version 0.17.0 of [Corepack][Node.js 16 Corepack]; see the corresponding [pull request][GitHub repository nodejs/node PR 46842]. 3.6.0 is the latest version of Yarn at this time. As stated in the [README][Node.js Corepack 0.17.0 README], a checksum should be specified: > The hash is optional but strongly recommended as a security practice. Version 0.17.0 of [Corepack][Node.js 16 Corepack] uses the function `createHash` of the [Node.js module `node:crypto`][Node.js 16 node:crypto]; see https://github.com/nodejs/corepack/blob/v0.17.0/sources/corepackUtils.ts#L138-L140. The hash/hashing algorithms that function supports "[…] is dependent on the available algorithms supported by the version of OpenSSL on the platform". I chose [SHA-512][SHA-2] because it strikes the best balance between safety/security and availability, as far as I know. [GitHub repository nodejs/corepack issue 231][] ```Shell curl -- https://repo.yarnpkg.com/3.6.0/packages/yarnpkg-cli/bin/yarn.js | sha512sum ``` ``` % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 2175k 0 2175k 0 0 3902k 0 --:--:-- --:--:-- --:--:-- 3899k 418e45c2268c4d6b69a28f3939084b5853d5f392c43c0b5588bd1995a96e328414ae4b7777a8980c64bad4328c52586ff879b289f98ae65372a55fa4d0ff70dd - ``` after setting `packageManager` in `package.json` with that checksum: ```Shell corepack yarn --version ``` ``` 3.6.0 ``` There's no difference between calling `corepack yarn` and calling the `yarn` shim installed by `corepack enable`; both are the same: ```JavaScript require('./corepack').runMain(['yarn', ...process.argv.slice(2)]); ``` the .js file is not committed and `yarnPath` is not set: yarnpkg/berry#4063 (comment) > Updating the binary in the repo, is temporary, until Corepack gets > available in all LTS releases. I think for Yarn 4 we'll consider only > updating the package.json. indeed, https://github.com/yarnpkg/berry/blob/master/CHANGELOG.md#major-changes > `yarn set version` will now skip generating the `yarnPath` > configuration on new projects if it detects you're using > [Corepack][Node.js Corepack] [GitHub repository nodejs/corepack issue 231]: nodejs/corepack#231 [GitHub repository nodejs/node PR 46842]: nodejs/node#46842 [GitHub repository yarnpkg/berry issue 4063]: yarnpkg/berry#4063 [Node.js changelog 16.20.0]: https://github.com/nodejs/node/blob/main/doc/changelogs/CHANGELOG_V16.md#16.20.0 [Node.js Corepack]: https://nodejs.org/api/corepack.html [Node.js Corepack 0.17.0 README]: https://github.com/nodejs/corepack/blob/v0.17.0/README.md [Node.js 16 Corepack]: https://nodejs.org/docs/latest-v16.x/api/corepack.html [Node.js 16 node:crypto]: https://nodejs.org/docs/latest-v16.x/api/crypto.html [SHA-2]: https://en.wikipedia.org/wiki/SHA-2

alper98 · 2024-03-04T22:31:22Z

This is still the case for me. Following the migration guide and running yarn set version berry still adds the yarnPath in my .yarnrc.yml file while also downloading the cjs

vishnup-ditto · 2024-03-08T11:53:05Z

This is still the case for me. Following the migration guide and running yarn set version berry still adds the yarnPath in my .yarnrc.yml file while also downloading the cjs

Similar update as this. The weirder part of me is it doesn't create a yarnPath for me in my linux machine, but it does for my colleague on a Windows machine. We both have corepack enabled. I think this is worth checking into again.

arcanis · 2024-03-08T12:01:21Z

This is still the case for me. Following the migration guide and running yarn set version berry still adds the yarnPath in my .yarnrc.yml file while also downloading the cjs

Yarn keeps any existing yarnPath field when upgrading if it already exists, to avoid altering projects when they upgrade from Yarn 3 to 4 and make the migration path simpler (in other words, yarnPath will only be removed for new projects, not existing ones).

So if you wish to switch to Corepack-only, you need to remove the yarnPath field from your .yarnrc.yml yourself.

vishnup-ditto · 2024-03-08T12:20:59Z

This is still the case for me. Following the migration guide and running yarn set version berry still adds the yarnPath in my .yarnrc.yml file while also downloading the cjs

Yarn keeps any existing yarnPath field when upgrading if it already exists, to avoid altering projects when they upgrade from Yarn 3 to 4 and make the migration path simpler (in other words, yarnPath will only be removed for new projects, not existing ones).

So if you wish to switch to Corepack-only, you need to remove the yarnPath field from your .yarnrc.yml yourself.

Thanks for the quick reply, what do you recommend about the yarn/release file this creates. Is that huge binary something we really need in our repos? The official Q&A suggests yes as I can see for this, but still it's a large file and I would like to not have it at all if possible!

alper98 · 2024-03-08T12:32:36Z

This is still the case for me. Following the migration guide and running yarn set version berry still adds the yarnPath in my .yarnrc.yml file while also downloading the cjs

Yarn keeps any existing yarnPath field when upgrading if it already exists, to avoid altering projects when they upgrade from Yarn 3 to 4 and make the migration path simpler (in other words, yarnPath will only be removed for new projects, not existing ones).

So if you wish to switch to Corepack-only, you need to remove the yarnPath field from your .yarnrc.yml yourself.

and then we can freely remove the binary from our repo, right?

arcanis · 2024-03-08T13:09:31Z

Yes, the binary can be removed once you removed the yarnPath setting 👍

qcn added the bug Something isn't working label Feb 2, 2022

merceyz added the not a bug label Feb 2, 2022

arcanis added the waiting for feedback Will autoclose in a while unless more data are provided label Feb 2, 2022

yarnbot added the stale Issues that didn't get attention label Mar 5, 2022

yarnbot closed this as completed Mar 10, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Bug?]: `yarn set version` sets `yarnPath` in `.yarnrc.yml` when using corepack to manage versions #4063

[Bug?]: `yarn set version` sets `yarnPath` in `.yarnrc.yml` when using corepack to manage versions #4063

qcn commented Feb 2, 2022

merceyz commented Feb 2, 2022 •

edited

Loading

qcn commented Feb 2, 2022

arcanis commented Feb 2, 2022

qcn commented Feb 2, 2022

yarnbot commented Mar 5, 2022

alper98 commented Mar 4, 2024 •

edited

Loading

vishnup-ditto commented Mar 8, 2024

arcanis commented Mar 8, 2024

vishnup-ditto commented Mar 8, 2024 •

edited

Loading

alper98 commented Mar 8, 2024

arcanis commented Mar 8, 2024

[Bug?]: yarn set version sets yarnPath in .yarnrc.yml when using corepack to manage versions #4063

[Bug?]: yarn set version sets yarnPath in .yarnrc.yml when using corepack to manage versions #4063

Comments

qcn commented Feb 2, 2022

Self-service

Describe the bug

To reproduce

Environment

Additional context

merceyz commented Feb 2, 2022 • edited Loading

qcn commented Feb 2, 2022

arcanis commented Feb 2, 2022

qcn commented Feb 2, 2022

yarnbot commented Mar 5, 2022

alper98 commented Mar 4, 2024 • edited Loading

vishnup-ditto commented Mar 8, 2024

arcanis commented Mar 8, 2024

vishnup-ditto commented Mar 8, 2024 • edited Loading

alper98 commented Mar 8, 2024

arcanis commented Mar 8, 2024

[Bug?]: `yarn set version` sets `yarnPath` in `.yarnrc.yml` when using corepack to manage versions #4063

[Bug?]: `yarn set version` sets `yarnPath` in `.yarnrc.yml` when using corepack to manage versions #4063

merceyz commented Feb 2, 2022 •

edited

Loading

alper98 commented Mar 4, 2024 •

edited

Loading

vishnup-ditto commented Mar 8, 2024 •

edited

Loading