[Bug] yarn set version berry writes absolute (non-portable) path into .yarnrc.yml

[cspotcode]

• I'd be willing to implement a fix

Describe the bug

yarn set version berry writes a .yarnrc.yml with an absolute path for yarnPath. I assume this is a bug since the .yarnrc.yml and .yarn/releases are meant to be portable and local.

To Reproduce

I created a reproduction with Github Actions that can also be copy-pasted to run locally.
https://github.com/cspotcode/repros/tree/yarnrc-absolute-yarnPath

Environment if relevant (please complete the following information):

• OS: Ubuntu
• Node version v12.15.0
• Yarn version 2.0.0-rc.28

[AlaricCalmette]

I came across the same issue. I tried to find where the issue was but was not successful. If someone could point me in the right direction I'd be glad to implement a fix.

[arcanis]

The first thing to figure out is whether the problem is truly the 2.x or rather the 1.x. The 2.x uses path.relative to reference the bundle, so I'm surprised it would end up absolute.

The 1.x, however, seems to use path.resolve which opens the door to an absolute path. If you want to lend a hand, I'd be happy to review the fix on the 1.x repository to release it in a 1.22.1!

[cspotcode]

I can't check right now but I assume it's the 1.x because it happens when I execute the command against a project without a .yarnrc, and I have yarn 1 globally installed.

…

On Mon, Feb 10, 2020, 9:09 AM Maël Nison ***@***.***> wrote: The first thing to figure out is whether the problem is truly the 2.x or rather the 1.x. The 2.x uses path.relative <https://github.com/yarnpkg/berry/blob/master/packages/plugin-essentials/sources/commands/set/version.ts#L207> to reference the bundle, so I'm surprised it would end up absolute. The 1.x, however, seems to use path.resolve <https://github.com/yarnpkg/yarn/blob/master/src/cli/commands/policies.js#L158> which opens the door to an absolute path. If you want to lend a hand, I'd be happy to review the fix on the 1.x repository to release it in a 1.22.1! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#921?email_source=notifications&email_token=AAC35OFURYZCCWEOMYBRK23RCFNYZA5CNFSM4KRUGUMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELIUGTQ#issuecomment-584139598>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC35OFBDV6UPMK25EEWU6DRCFNYZANCNFSM4KRUGUMA> .

[Daniel15]

Should we move this issue to the 1.x repo?

[danielleadams]

I was also seeing this, and it happens with 1.x too. If I install yarn 1.x then run yarn set version berry, it will write the absolute path to .yarnrc.yml.

[doums]

Same story happen for me.

[ghost]

Same --

1. Per instructions, installed yarn 1.22 as global
2. Ran yarn set version berry
   • this created .yarnrc.yml with the absolute path to .yarn/yarn-rc.yml
3. Ran yarn set version berry
   • this set .yarnrc.yml with the relative path to .yarn/yarn-rc.yml

It seems like the work around is to run yarn set version berry twice in a row, until they update the global yarn install version.

[dzintars]

Some observation from my side.
Recently i ditched Yarn 1 & friends from system and set up clean Yarn 2 Berry. The only Yarn on my Linux system. Created some project and it had yarnPath: .yarn/releases/yarn-rc.js
Today i decided to convert my WebPack configs in TS which led me again to Yarn's documentation which says that they move to Per-Project installation workflow which sounds reasonable to me. So i ditched again my Yarn 2, Node, Npm & frieds (simply to have clean setup). Installed Yarn 1.23 as per instructions. + Node 13.9.0, Npm 6.13.7
Now, when i do yarn set version berry is see .yarnrc.yml created but with content yarnPath: "/home/dzintars/Code/yarn-test/.yarn/releases/yarn-berry.js"

Other thing is... as soon as i enable "type": "module", in package.json Yarn Berry fails to execute even yarn --version with:

(node:42700) ExperimentalWarning: The ESM module loader is experimental.
file:///home/dzintars/Code/yarn-test/.yarn/releases/yarn-berry.js:2
[.... some minified long output ....]
ReferenceError: module is not defined
    at file:///home/dzintars/Code/yarn-test/.yarn/releases/yarn-berry.js:2:1
    at ModuleJob.run (internal/modules/esm/module_job.js:110:37)
    at async Loader.import (internal/modules/esm/loader.js:167:24)

So.. it looks to me that there are some issues with 2 versions installed on the system.

[cspotcode]

Probably this is because yarn's local copy is being loaded as an esm module, because node thinks it's supposed to do that according to package.json. I imagine it could be fixed by having yarn emit its own package.json as a peer to the local copy of yarn.

…

On Thu, Feb 20, 2020, 7:59 PM Dzintars Klavins ***@***.***> wrote: Some observation from my side. Recently i ditched Yarn 1 & friends from system and set up clean Yarn 2 Berry. The only Yarn on my Linux system. Created some project and it had yarnPath: .yarn/releases/yarn-rc.js Today i decided to convert my WebPack configs in TS which lead me again to Yarns documentation which says that they move to Per-Project installation workflow which sounds reasonable to me. So i ditched again my Yarn 2, Node, Npm & frieds (simply to have clean setup). Installed Yarn 1.23 as per instructions. Now, when i do yarn set version berry is see .yarnrc.yml created but with content yarnPath: "/home/dzintars/Code/yarn-test/.yarn/releases/yarn-berry.js" Other thing is... as soon as i enable "type": "module", in package.json Yarn Berry fails to execute even yarn --version with: (node:42700) ExperimentalWarning: The ESM module loader is experimental. file:///home/dzintars/Code/github.com/dzintars/yarn-test/.yarn/releases/yarn-berry.js:2 [.... some minified long output ....] ReferenceError: module is not defined at file:///home/dzintars/Code//yarn-test/.yarn/releases/yarn-berry.js:2:1 at ModuleJob.run (internal/modules/esm/module_job.js:110:37) at async Loader.import (internal/modules/esm/loader.js:167:24) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#921?email_source=notifications&email_token=AAC35OBMDMCAQ4KVATI47FTRD4RPXA5CNFSM4KRUGUMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMRD7RQ#issuecomment-589447110>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC35OGKQSQSIIQUKWDF5UTRD4RPXANCNFSM4KRUGUMA> .

[dzintars]

Sorry, i can't to get right wording.. but.. when i run yarn set version berry first time it is run by my global 1.23 version.. right? But next time i run yarn [...] from same directory it should be executed by 2.x? Not sure how all that works.

[cspotcode]

Correct. The globally-installed yarn will always check if you have a locally-configured copy of yarn. If you do, it will load and delegate to that locally-configured copy.

node 13 loads modules as either commonjs or esm depending on a few factors. This page explains how it reads the "type" field from your package.json. Since the local copy of yarn is inside your project's directory, node thinks it's part of your project, and loads it according to the package.json "type" field for your project. yarn can avoid this by emitting another nested package.json within the .yarn subdirectory.

[petterw03]

I'm having the same issue and am very confused. Followed the installation instruction using Yarn 1.22.0 on Windows.

$ yarn set version berry
Resolving berry to a url...
Downloading https://github.com/yarnpkg/berry/raw/master/packages/berry-cli/bin/b
erry.js...
Saving it into C:\jobb\2020-01-raseborg_trafik\.yarn\releases\yarn-berry.js...
Updating C:\jobb\2020-01-raseborg_trafik/.yarnrc.yml...
Done!

The resulting .yarnrc.yml:

yarnPath: "C:\\jobb\\2020-01-raseborg_trafik\\.yarn\\releases\\yarn-berry.js"

[gregoryjjb]

Seeing the same issue (2.0.0-rc.29), can confirm running yarn set version berry will fix it (it also changes the paths to Unix-style), but manually removing the absolute portion of the path in .yarnrc.yml works too.

[chenxsan]

If you run yarn set version berry under yarn 1.x, you will get absolute path in .yarnrc.yml. Run yarn set version berry again you should get the relative one: yarnPath: .yarn/releases/yarn-rc.js. So it's a problem of 1.x.

[petterw03]

A fix seems to have been merged into the 1.x repo: yarnpkg/yarn#7931

[arcanis]

Released in 1.22.4