corepack seems to obey LOCALAPPDATA silently #673

quotidian-ennui · 2025-03-07T11:26:52Z

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

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

MikeMcC399 · 2025-03-17T06:16:47Z

@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.

See README > Troubleshooting.

quotidian-ennui · 2025-03-17T09:06:08Z

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

aduh95 · 2025-03-17T09:47:32Z

I don't know about "silently", the README says this:

corepack/README.md

Lines 334 to 335 in 19e3c68

    
           - `COREPACK_HOME` can be set in order to define where Corepack should install 
        
             the package managers. By default it is set to `%LOCALAPPDATA%\node\corepack`

But anyway, I agree we could try to improve the error output and/or the README to help users with this issue, PRs welcome

MikeMcC399 · 2025-03-17T11:56:42Z

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.

corepack/README.md

Lines 334 to 337 in 19e3c68

    
           - `COREPACK_HOME` can be set in order to define where Corepack should install 
        
             the package managers. By default it is set to `%LOCALAPPDATA%\node\corepack` 
        
             on Windows, and to `$HOME/.cache/node/corepack` everywhere else.

MikeMcC399 · 2025-03-17T12:25:39Z

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.

MikeMcC399 · 2025-03-17T12:38:44Z

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

MikeMcC399 · 2025-03-18T08:38:52Z

@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".

quotidian-ennui · 2025-03-18T09:06:05Z

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.

MikeMcC399 · 2025-03-18T09:26:30Z

@quotidian-ennui

Great to hear you have a useable workaround!

MikeMcC399 · 2025-03-18T09:30:43Z

It seems the error is in

corepack/sources/folderUtils.ts

Lines 14 to 24 in 19e3c68

    
           export function getCorepackHomeFolder() { 
        
             return ( 
        
               process.env.COREPACK_HOME ?? 
        
               join( 
        
                 process.env.XDG_CACHE_HOME ?? 
        
                   process.env.LOCALAPPDATA ?? 
        
                   join(homedir(), process.platform === `win32` ? `AppData/Local` : `.cache`), 
        
                 `node/corepack`, 
        
               ) 
        
             ); 
        
           }

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.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

corepack seems to obey LOCALAPPDATA silently #673

corepack seems to obey LOCALAPPDATA silently #673

quotidian-ennui commented Mar 7, 2025

MikeMcC399 commented Mar 17, 2025

quotidian-ennui commented Mar 17, 2025 •

edited

Loading

aduh95 commented Mar 17, 2025

MikeMcC399 commented Mar 17, 2025 •

edited

Loading

MikeMcC399 commented Mar 17, 2025

MikeMcC399 commented Mar 17, 2025 •

edited

Loading

MikeMcC399 commented Mar 18, 2025

quotidian-ennui commented Mar 18, 2025

MikeMcC399 commented Mar 18, 2025

MikeMcC399 commented Mar 18, 2025 •

edited

Loading

corepack seems to obey LOCALAPPDATA silently #673

corepack seems to obey LOCALAPPDATA silently #673

Comments

quotidian-ennui commented Mar 7, 2025

MikeMcC399 commented Mar 17, 2025

quotidian-ennui commented Mar 17, 2025 • edited Loading

aduh95 commented Mar 17, 2025

MikeMcC399 commented Mar 17, 2025 • edited Loading

MikeMcC399 commented Mar 17, 2025

MikeMcC399 commented Mar 17, 2025 • edited Loading

Logs

MikeMcC399 commented Mar 18, 2025

quotidian-ennui commented Mar 18, 2025

MikeMcC399 commented Mar 18, 2025

MikeMcC399 commented Mar 18, 2025 • edited Loading

quotidian-ennui commented Mar 17, 2025 •

edited

Loading

MikeMcC399 commented Mar 17, 2025 •

edited

Loading

MikeMcC399 commented Mar 17, 2025 •

edited

Loading

MikeMcC399 commented Mar 18, 2025 •

edited

Loading