nodejs
corepack seems to obey LOCALAPPDATA silently
Platform : WSL2
If because of reasons you have WSLENV=WT_SESSION:WT_PROFILE_ID:LOCALAPPDATA/p:USERPROFILE/p:APPDATA/p to pass through LOCALAPPDATA & APPDATA to your WSL2 environment then you get permissions errors when trying to use yarn + corepack
bsh ❯ corepack enable
bsh ❯ COREPACK_ENABLE_DOWNLOAD_PROMPT=0 yarn install
node:internal/fs/promises:783
return await PromisePrototypeThen(
^
Error: EACCES: permission denied, rename '/mnt/c/Users/.../AppData/Local/node/corepack/v1/corepack-774055-2af6683f.7bd48' -> '/mnt/c/Users/.../AppData/Local/node/corepack/v1/yarn/4.7.0'
at async Object.rename (node:internal/fs/promises:783:10)
at async renameSafe (/home/.../.nvm/versions/node/v22.14.0/lib/node_modules/corepack/dist/lib/corepack.cjs:21935:5)
at async installVersion (/home/.../.nvm/versions/node/v22.14.0/lib/node_modules/corepack/dist/lib/corepack.cjs:21903:5)
at async Engine.ensurePackageManager (/home/.../.nvm/versions/node/v22.14.0/lib/node_modules/corepack/dist/lib/corepack.cjs:22323:32)
at async Engine.executePackageManagerRequest (/home/.../.nvm/versions/node/v22.14.0/lib/node_modules/corepack/dist/lib/corepack.cjs:22423:25)
at async Object.runMain (/home/.../.nvm/versions/node/v22.14.0/lib/node_modules/corepack/dist/lib/corepack.cjs:23110:7) {
errno: -13,
code: 'EACCES',
syscall: 'rename',
path: '/mnt/c/Users/.../AppData/Local/node/corepack/v1/corepack-774055-2af6683f.7bd48',
dest: '/mnt/c/Users/.../AppData/Local/node/corepack/v1/yarn/4.7.0'
}
This never used to happen, and I'm not sure if it's 'yarn' or 'corepack' that is the issue (there aren't any PRs or issues that mention appdata that seem related).
My current workaround is to use direnv to unset both those environment variables
@quotidian-ennui
This sounds like it is a configuration issue with WSL2 that you have already resolved with your workaround, not a bug in Corepack or Yarn.
If you think it is a bug in Corepack, I suggest you re-run your commands with DEBUG=corepack enabled and post the results here:
corepack enable yarn
export DEBUG=corepack
COREPACK_ENABLE_DOWNLOAD_PROMPT=0 yarn install
Please mention also which Linux distro you are running in WSL2.
I agree that it's not a technical bug in corepack (or yarn); however, it is an edge case that deserves to be documented. I wouldn't have raised it if there was obvious documentation about "what environment variables will always override the default location for cache storage" (or whatever this is); there isn't, or it wasn't obviously searchable.
Happy for you to close this as you see fit; it's here so that it's not some xkcd#959
I don't know about "silently", the README says this: https://github.com/nodejs/corepack/blob/19e3c6861a8affdfd94d97edf495c21e591fe4e0/README.md?plain=1#L334-L335
But anyway, I agree we could try to improve the error output and/or the README to help users with this issue, PRs welcome
I tried setting WSLENV=WT_SESSION:WT_PROFILE_ID:LOCALAPPDATA/p:USERPROFILE/p:APPDATA/p in Windows 11 then running the following in Ubuntu 24.04.2 LTS under WSL2 with [email protected]:
cd $(mktemp -d)
rm -rf $LOCALAPPDATA/node/corepack
rm -rf ~/.cache/node/corepack
corepack enable yarn
export DEBUG=corepack
corepack use yarn@latest
$ echo $WSLENV
WT_SESSION:WT_PROFILE_ID:LOCALAPPDATA/p:USERPROFILE/p:APPDATA/p
$ corepack enable yarn
export DEBUG=corepack
corepack use yarn@latest
Installing [email protected] in the project...
corepack Installing [email protected] from https://repo.yarnpkg.com/4.7.0/packages/yarnpkg-cli/bin/yarn.js +0ms
corepack Downloading to /mnt/c/Users/mikem/AppData/Local/node/corepack/v1/corepack-312-d744b221.5bf8 +10ms
corepack LastKnownGood file would be located at /mnt/c/Users/mikem/AppData/Local/node/corepack/lastKnownGood.json +424ms
corepack No LastKnownGood version found in Corepack home. +4ms
corepack Download and install of [email protected] is finished +0ms
corepack Checking /tmp/tmp.cPqWVAxuCz/package.json +0ms
➤ YN0000: · Yarn 4.7.0
➤ YN0000: ┌ Resolution step
➤ YN0000: └ Completed
➤ YN0000: ┌ Fetch step
➤ YN0000: └ Completed
➤ YN0000: ┌ Link step
➤ YN0000: └ Completed
➤ YN0000: · Done in 0s 36ms
I see that Corepack is using LOCALAPPDATA even though it is running under Ubuntu. I would have expected it to ignore that environment variable. Normally I would expect Corepack to act like it is running in a pure Linux environment, and ignore the fact that this is a virtual Linux running under a Windows host. So now I do think that it is a Corepack bug.
https://github.com/nodejs/corepack/blob/19e3c6861a8affdfd94d97edf495c21e591fe4e0/README.md?plain=1#L334-L337
This is also reproducible in a pure Ubuntu environment with no WSL2 involved.
If LOCALAPPDATA is defined under Ubuntu, then Corepack is using it to build the cache location.
To reproduce on Ubuntu:
npm install corepack@latest -g
mkdir $HOME/localappdata
export LOCALAPPDATA="$HOME/localappdata"
rm -rf $LOCALAPPDATA/node
rm -rf ~/.cache/node
cd $(mktemp -d)
corepack enable yarn
export DEBUG=corepack
corepack install -g yarn@latest
find $LOCALAPPDATA
find ~/.cache/node
Logs
Installing [email protected]...
corepack Installing [email protected] from https://repo.yarnpkg.com/4.7.0/packages/yarnpkg-cli/bin/yarn.js +0ms
corepack Downloading to /home/mike/localappdata/node/corepack/v1/corepack-4798-871d3ee9.a67eb +1ms
corepack LastKnownGood file would be located at /home/mike/localappdata/node/corepack/lastKnownGood.json +343ms
corepack No LastKnownGood version found in Corepack home. +1ms
corepack Download and install of [email protected] is finished +0ms
corepack LastKnownGood file would be located at /home/mike/localappdata/node/corepack/lastKnownGood.json +0ms
corepack No LastKnownGood version found in Corepack home. +0ms
corepack Setting [email protected] as Last Known Good version +0ms
corepack LastKnownGood file would be located at /home/mike/localappdata/node/corepack/lastKnownGood.json +1ms
/home/mike/localappdata
/home/mike/localappdata/node
/home/mike/localappdata/node/corepack
/home/mike/localappdata/node/corepack/lastKnownGood.json
/home/mike/localappdata/node/corepack/v1
/home/mike/localappdata/node/corepack/v1/yarn
/home/mike/localappdata/node/corepack/v1/yarn/4.7.0
/home/mike/localappdata/node/corepack/v1/yarn/4.7.0/.corepack
/home/mike/localappdata/node/corepack/v1/yarn/4.7.0/yarn.js
find: ‘/home/mike/.cache/node’: No such file or directory
@quotidian-ennui
Although I'm able to reproduce Corepack using the wrong cache directory under a pure Linux environment, I wasn't able to reproduce your Error: EACCES: permission denied error on rename. When I set the LOCALAPPDATA directory to read-only, I got a user-friendly error message. I see you were using Node.js 22.14.0, so I assume that you were using the bundled Corepack 0.31.0.
The rename error is in any case a separate issue, and the title of the issue here is "corepack seems to obey LOCALAPPDATA silently".
That's cool, I feel the ENOACCESS error is down to the very specific way NTFS is setup round here (something blah blah AD permissions not inherited by WSL2 something something), and it's a red herring.
I agree that your investigations (thanks!) show that the problem is LOCALAPPDATA being used regardless of platform. WSL2 should be treated as vanilla linux by corepack.
I've got a usable workaround (I'm not a nodejs dev by trade) so it's not breaking my workflow which is mostly AWS CDK.
It seems the error is in https://github.com/nodejs/corepack/blob/19e3c6861a8affdfd94d97edf495c21e591fe4e0/sources/folderUtils.ts#L14-L24
where process.env.LOCALAPPDATA is used if it is defined, no matter which operating system is running.
npm, pnpm and Yarn all are using LOCALAPPDATA only on Windows.
kinda unrelated, but we ran into this as we were settings XDG_CACHE_HOME to handle where puppeteer was saving its crashpads with chromium, setting COREPACK_HOME got our location to win
