berry
berry copied to clipboard
[Bug?]: Unknown error on link step
Self-service
- [ ] I'd be willing to implement a fix
Describe the bug
I'm migrating a project from yarn classic. When installing I get an unknown error. It could be related to file permissions but I'm not sure.
$ yarn
➤ YN0000: · Yarn 4.0.2
➤ YN0000: ┌ Resolution step
➤ YN0000: └ Completed in 0s 277ms
➤ YN0000: ┌ Fetch step
➤ YN0000: └ Completed in 0s 825ms
➤ YN0000: ┌ Link step
➤ YN0001: │ Error: UNKNOWN: unknown error, link 'C:\Users\vis97\AppData\Local\Yarn\Berry\index\a1\a1e9c52af8059502374c7d5be53fee0ba63343a8.dat' -> 'C:\projects\xamu\store\node_modules\.store\@firebase-auth-virtual-b1241dd24a\package\dist\cordova\src\core\credentials\oauth.test.d.ts'
➤ YN0000: └ Completed in 13s 394ms
➤ YN0000: · Failed with errors in 14s 586ms
node:internal/process/promises:288
triggerUncaughtException(err, true /* fromPromise */);
^
[Error: UNKNOWN: unknown error, link 'C:\Users\vis97\AppData\Local\Yarn\Berry\index\a1\a1e9c52af8059502374c7d5be53fee0ba63343a8.dat' -> 'C:\projects\xamu\store\node_modules\.store\@firebase-auth-virtual-b1241dd24a\package\dist\cordova\src\core\credentials\oauth.test.d.ts'] {
errno: -4094,
code: 'UNKNOWN',
syscall: 'link',
path: 'C:\\Users\\vis97\\AppData\\Local\\Yarn\\Berry\\index\\a1\\a1e9c52af8059502374c7d5be53fee0ba63343a8.dat',
dest: 'C:\\projects\\xamu\\store\\node_modules\\.store\\@firebase-auth-virtual-b1241dd24a\\package\\dist\\cordova\\src\\core\\credentials\\oauth.test.d.ts'
}
Node.js v18.19.0
Thanks in advance!
To reproduce
// package.json
{
"private": true,
"packageManager": "[email protected]",
"engines": {
"node": ">=18"
},
"dependencies": {
"firebase": "^10.7.1"
}
}
# yarnrc.yml
nodeLinker: pnpm
Environment
System:
OS: Windows 11 10.0.22631
CPU: (8) x64 AMD Ryzen 7 4700U with Radeon Graphics
Binaries:
Node: 18.19.0 - ~\AppData\Local\Temp\xfs-9666f8ad\node.CMD
Yarn: 4.0.2 - ~\AppData\Local\Temp\xfs-9666f8ad\yarn.CMD
npm: 10.2.3 - C:\Program Files\nodejs\npm.CMD
Additional context
Already tried installing after removing firebase but the issue just passes to other packages
Closing since this issue is related to nuxt: https://github.com/nuxt/nuxt/issues/22861
@vis97c I have reopened your issue, since there are higher chances this is Yarn Modern issue, not nuxt. Plus comment you transitively refer to:
https://github.com/nuxt/nuxt/issues/15774#issuecomment-1397418341
talks about pnp support, and you are using pnpm linker, which is a different install strategy.
I think it is either Yarn's bug or something with permissions on your machine.
@larixer No need to reopen, as to clarify why:
The yarn part of the issue comes from the fact that postinstall scripts run on link step. I was using that to prebuild nuxt types, but since nuxt couln't at the time handle yarn nor pnm module resolution it was breaking the script execution, that is why it failed not matter what modules I uninstalled. So for yarn the nuxt error mean that the install had an "unknown error".
The solution as listed on the nuxt docs is to setup nodeLinker to use node_modules resolution. https://nuxt.com/docs/getting-started/installation#new-project
If there is something else I should be considering let me know. Still I think there is no more reason for this issue.
I have the same issue with a different package.
// package.json
{
"name": "mui-repro",
"version": "1.0.0",
"main": "index.js",
"license": "MIT",
"packageManager": "[email protected]",
"dependencies": {
"@mui/icons-material": "^5.15.11"
}
}
This package works with yarn 3, but since upgrading on yarn 4, on Windows I get the following error
C:\projects\mui-repro>yarn
➤ YN0000: · Yarn 4.1.0
➤ YN0000: ┌ Resolution step
➤ YN0000: └ Completed in 0s 479ms
➤ YN0000: ┌ Post-resolution validation
➤ YN0002: │ mui-repro@workspace:. doesn't provide @mui/material (p694a4), requested by @mui/icons-material.
➤ YN0002: │ mui-repro@workspace:. doesn't provide react (p7a37d), requested by @mui/icons-material.
➤ YN0086: │ Some peer dependencies are incorrectly met; run yarn explain peer-requirements <hash> for details, where <hash> is the six-letter p-prefixed code.
➤ YN0000: └ Completed
➤ YN0000: ┌ Fetch step
➤ YN0013: │ 3 packages were added to the project, and 3 were removed (+ 1.02 KiB).
➤ YN0000: └ Completed
➤ YN0000: ┌ Link step
➤ YN0001: │ Error: UNKNOWN: unknown error, link 'C:\Users\mikef\AppData\Local\Yarn\Berry\index\e6\e6c07a0189cae2df31aeecea0e3e386449df7918.dat' -> 'C:\projects\mui-repro\node_modules\.store\@mui-icons-material-virtual-9d00a93aea\package\Abc.d.ts'
➤ YN0000: └ Completed in 7s 199ms
➤ YN0000: · Failed with errors in 7s 872ms
[Error: UNKNOWN: unknown error, link 'C:\Users\mikef\AppData\Local\Yarn\Berry\index\e6\e6c07a0189cae2df31aeecea0e3e386449df7918.dat' -> 'C:\projects\mui-repro\node_modules\.store\@mui-icons-material-virtual-9d00a93aea\package\Abc.d.ts'] {
errno: -4094,
code: 'UNKNOWN',
syscall: 'link',
path: 'C:\\Users\\mikef\\AppData\\Local\\Yarn\\Berry\\index\\e6\\e6c07a0189cae2df31aeecea0e3e386449df7918.dat',
dest: 'C:\\projects\\mui-repro\\node_modules\\.store\\@mui-icons-material-virtual-9d00a93aea\\package\\Abc.d.ts'
}
Node.js v20.6.1
Yes going to node-modules instead of pnpm solves the problem, but I have to evaluate with my team if we want to go ahead with that change since it has other impacts. My main concern is the cryptic error and I just don't know how to start investigate
Edit: I tried and it seems going to node-modules is not a viable option in the short term because the project relies on different libraries in the monorepo to import the same package in the store
For now I'm reverting back to yarn 3
If it helps, running the link command manually gives this output
link 'C:\Users\mikef\AppData\Local\Yarn\Berry\index\e6\e6c07a0189cae2df31aeecea0e3e386449df7918.dat' 'C:\projects\repro\node_modules\.store\@mui-icons-material-virtual-81713531c3\package\Abc.d.ts'
link: cannot create link 'C:\projects\mui-repro\node_modules\.store\@mui-icons-material-virtual-81713531c3\package\Abc.d.ts' to 'C:\Users\mikef\AppData\Local\Yarn\Berry\index\e6\e6c07a0189cae2df31aeecea0e3e386449df7918.dat': Too many links
This bug still persists in yarn 4.x pnp.
Build log: