Fix: nested relative link: protocal dependency symlinks

[stipsan]

When a link:a dependency also contain a link:b the symlink to link:b is broken.
I'm not sure how to fix it yet as I've never looked at Yarn's sourcecode before but at least I got a proper test case that reproduces the problem to get the ball rolling 😄

Expected test output in this PR (until the bug is fixed):

 FAIL  __tests__/commands/install/integration.js (64.908s)
  ● resolves the symlinks of other symlinked packages relative to the package using the link: protocol

    Error: expect(received).toEqual(expected)

    Expected value to equal:
      "../a/b"
    Received:
      "../b"

Edit

Seems like file-resolver have a solution for this already so I've pushed a patch to link-resolver that use the same logic. Hopefully it solves the problem 😃

[arcanis]

I'm not sure I totally understand what you mean - the link: protocol just creates a symlink to a location, that's it. It doesn't install any nested dependency.

[stipsan]

@arcanis if you look at the test case I added here you can observe that it does resolve dependencies of a link, and that behavior happens before applying my fix.

I thought this behavior was a feature? That's why I tried to fix the broken symlinks that result from nested dependencies 😄

[bestander]

So do I understand it right?

root
  -- > link: a --> link: b

Gets installed

node_modules
  a (symlink) -> ../a
  b (symlink) -> ../a/b

[bestander]

I am worried that we touch what is inside a, probably a symlinked dependency should not participate in deduping?

And be like

node_modules/
  a (symlink) -> ../a

a/ 
  b/
  node_modules/
  b (symlink) -> ../b

I wonder if several projects will link to a, would they be modifying their contents

[stipsan]

Yes the following is what gets installed:

node_modules
  a (symlink) -> ../a
  b (symlink) -> ../a/b

This is however what is getting installed on develop currently:

node_modules
  a (symlink) -> ../a
  b (symlink) -> ../b

And that means the b symlink is going nowhere. I can't comment on deduping and that behavior as I'm new to the yarn codebase and have only basic understanding on resolvers in general and ExoticResolver logic specifically 😕

I can dig into it though and add a test case regarding:

I wonder if several projects will link to a, would they be modifying their contents

[bestander]

Ah, yeah, looks like it is fine then.
We'll probably be discovering more issues with transitive link: and file: dependencies, we'll deal with them as they come.
Feel free to investigate a bit more.

[bestander]

Thanks, @stipsan, good fix!