Berry: [Bug] Windows symlink problem

[zdm]

• [*] I'd be willing to implement a fix

Describe the bug
I think, that Sherlock is useless for windows, so I will not use it for this issue.

When the project is located in the folder, which is symbolic link, and I perform yarn install or yarn add from this folder - it creates .pnp.js file with incorrect packageLocation for dependencies.
packageLocation created related to the symbolic link, but it should be related to the original location.
Under linux yarn resolves symbolic links during .pnp.js creation, but under windows - not (seems, you forgot to do this).

I think, I can fix it, if you give me directions, where I should look for a code, responding for .pnp.js generation under windows.

Here is the script, that setup folders structure and reproduce the issue, it should be executed with admin permissions, because mklink under windows requires elevated permissions:

:: create original project location
rmdir /S /Q 1
mkdir 1\2\3\project

:: create symbolic link to the project
rmdir project
mklink /D project 1\2\3\project

:: init project
cd %~dp0\project
call yarn init
call yarn add eslint

:: test
call yarn eslint --version

cd %~dp0

pause

[arcanis]

I tried out your repro but everything looks fine to me, I believe some information is missing. What is the exact error you see? What are the relative paths, and what should they look like? Is your cache on a different drive as your application?

[zdm]

eslint packageLocation:

"packageLocation": "../../../../C:/Users/zdm/.yarn/global/cache/@babel-code-frame-npm-7.5.5-7f826ed8c4-1.zip/node_modules/@babel/code-frame/"

But it should be

"packageLocation": "../../../../../../../C:/Users/zdm/.yarn/global/cache/@babel-code-frame-npm-7.5.5-7f826ed8c4-1.zip/node_modules/@babel/code-frame/"          

Error

d:\downloads\222\1\2\3\project\.pnp.js:9308
    throw firstError;
    ^

Error: Couldn't find a suitable Node resolution for the specified unqualified path

Source path: /d:/downloads/222/C:/Users/zdm/.yarn/global/cache/eslint-npm-6.8.0-d27045f313-1.zip/node_modules/eslint/bin/eslint.js
Rejected resolution: /d:/downloads/222/C:/Users/zdm/.yarn/global/cache/eslint-npm-6.8.0-d27045f313-1.zip/node_modules/eslint/bin/eslint.js
Rejected resolution: /d:/downloads/222/C:/Users/zdm/.yarn/global/cache/eslint-npm-6.8.0-d27045f313-1.zip/node_modules/eslint/bin/eslint.js.js
Rejected resolution: /d:/downloads/222/C:/Users/zdm/.yarn/global/cache/eslint-npm-6.8.0-d27045f313-1.zip/node_modules/eslint/bin/eslint.js.json
Rejected resolution: /d:/downloads/222/C:/Users/zdm/.yarn/global/cache/eslint-npm-6.8.0-d27045f313-1.zip/node_modules/eslint/bin/eslint.js.node

    at internalTools_makeError (d:\downloads\222\1\2\3\project\.pnp.js:9082:24)
    at resolveUnqualified (d:\downloads\222\1\2\3\project\.pnp.js:10120:13)
    at resolveRequest (d:\downloads\222\1\2\3\project\.pnp.js:10145:14)
    at Object.resolveRequest (d:\downloads\222\1\2\3\project\.pnp.js:10235:26)
    at Function.external_module_default.a._resolveFilename (d:\downloads\222\1\2\3\project\.pnp.js:9296:29)
    at Function.external_module_default.a._load (d:\downloads\222\1\2\3\project\.pnp.js:9198:50)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:71:12)
    at internal/main/run_main_module.js:17:47 {
  code: 'MODULE_NOT_FOUND',
  pnpCode: 'QUALIFIED_PATH_RESOLUTION_FAILED',
  data: {
    unqualifiedPath: '/d:/downloads/222/C:/Users/zdm/.yarn/global/cache/eslint-npm-6.8.0-d27045f313-1.zip/node_modules/eslint/bin/eslint.js',
    request: '/d:/downloads/222/C:/Users/zdm/.yarn/global/cache/eslint-npm-6.8.0-d27045f313-1.zip/node_modules/eslint/bin/eslint.js',
    issuer: '/d:/downloads/222/project/'
  },
  requireStack: []
}

[zdm]

This is definitely symlink problem.
When I run install and test from original directory - everything is OK, packageLocation is correct.
But when I run install and test from symlink folder, I get ERROR and packageLocation is related to symlink. I think, it should be related to the original folder, like in linux. I guess, that .pnp.js resolves project folder symlink during runtime and packageLocation should be stored relative to the resolved location.

[arcanis]

Is it still the case with the latest release? I remember fixing some stuff that might be related.

[zdm]

I will check again, but RC-19 was the latest version, that worked for me.

[zdm]

So, this issues is still present in RC-23.
If you will find a time - I can give all possible help in debugging and testing.
This is definitely problem with thw unresolved symlink.

[PabloSzx]

After the announcement and reading about all the new features I was very interested in it, and then I tried using it, and in windows it simply doesn't work, and it seems to be related to this issue.

All I get trying to execute anything with yarn v2 is this:

.pnp.js:34280
    throw firstError;
    ^

Error: Couldn't find a suitable Node resolution for the specified unqualified path

Source path: /C:/Program
Rejected resolution: /C:/Program
Rejected resolution: /C:/Program.js
Rejected resolution: /C:/Program.json
Rejected resolution: /C:/Program.node
Rejected resolution: /C:/Program.mjs

EDIT: I made a repo with examples showcasing the problem https://github.com/PabloSzx/yarn_berry_windows_bug

[mustafahlvc]

I ve encountered the same issue with @PabloSzx

Possibly the issue related with nvm-windows at least for me,
removed nvm-windows and installing node.js with regular way solved the problem.

[yarnbot]

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 resolution faster). 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.

[zdm]

This is windows - only issue, that still requires fix.