feat(node-modules): Portal support

[larixer]

What's the problem this PR addresses?

This PR adds support for portals to the node-modules linker. The application that uses portals must be started with --preserve-symlinks Node option. Only those portals that point inside project directory or have no conflicting dependencies with their parent package are representable in node_modules installs and are supported. When conflict is found, the nm linker outputs error and abandons install.

How did you fix it?

Portal dependencies are now added to the dependency graph before hoisting. Conflicts in portal dependencies are detected and reported.

This PR also fixes #2266

CC: @andreialecu

Checklist

• I have read the Contributing Guide.

• I have set the packages that need to be released for my changes to be effective.

• I will check that all automated PR checks pass before the PR gets reviewed.

[arcanis]

Would it be worth to have the linker print a warning explaining that --preserve-symlinks will be required for the install to properly behave? Users will be able to filter it out with logFilters if they so wish, but without it I'm worried they would try running the program as usual, see it fail, and think it's a bug.

[larixer]

Yes, I think, it makes sense, I will add the warning, when any of portal targets has at least one dependency (otherwise the --preserve-symlinks are not needed, if all portal targets have zero dependencies)

[andreialecu]

This is currently still missing the workspace protocol support, correct?

[larixer]

@andreialecu I'm not sure what do you mean, the workspace protocol had always been fully supported by nm linker

[merceyz]

This is currently still missing the workspace protocol support, correct?

The core doesn't resolve the workspace protocol from external projects so it's unrelated to this PR

[andreialecu]

@larixer sorry for not being clear enough, I'm referring to the discussion on Discord here: https://discord.com/channels/226791405589233664/226793713722982400/810902897947836466

[larixer]

Switched to a draft, because apparently if portal target is inside the project and it is used more than once, the portal must be fully hoistable too, otherwise multiple hoisting layouts will arise for such a portal which will lead to broken install. Going to implement this extra constraint here

[larixer]

Actually in the case above the inner portal MUST NOT be fully hoistable, it must have SINGLE hoisting layout. Hence, this PR is okay. There are two other problems that should be addressed in follow up PRs, but these problems existed for long time already and not directly related to portals:

• The problem that soft links must have only SINGLE hoisting layout. After much thinking about this problem I came to conclusion that this needs to be implemented as strict addition to the current hoisting algorithm in a form of finding common hoisting layout satisfying all instances of a given SOFT link. The code of uniting hoisting layouts for a SOFT link currently exists in buildNodeModulesTree and is simply incomplete and hence incorrect, it must be transferred instead to the hoisting code, completed and unit tests should be added to cover it.
• The other problem is tracing peer dependencies of a SOFT link. If SOFT link inherits dependency from the folder that is not PARENT on the file system, then --preserve-symlinks option must be used, otherwise it will not find peer dependency correctly. This peer tracing should be implemented in a separate PR. I believe this case appears seldom in practice, but Yarn should detect it and warn with diagnostic info.