Autolinking doesn't work well with yarn link

[asklar]

1. add a module to an app, autolink it. sln and project files get pointed at the copy under node_modules
2. clone the module repo, yarn link it, link it into the app.

expected: autolink is not needed actual: autolink is needed because it thinks myapp\node_modules\mymodule is different than C:\mymodule_clone... in other words, autolinking is using the real ("target") filesystem path, which breaks the symlink abstraction

[chrisglein]

Paths are the targets of symlinks, not the symlinks itself. Logic there needs to be tidied up. @jonthysell if you have ideas on how this should work, copy them in here.

[jonthysell]

The path to the dependency dir (under node_modules) is determined by the RN core CLI's react-native config command, and is passed to us fully resolved. By the time we get it, we can't possibly know that the path was gotten through a symlink without re-searching for the dependency (and potentially getting it wrong).

However, starting in v9.0.0-alpha.5 of the RN CLI, the dependency dir logic has been updated to not automatically resolve the symlink by default (see findPackageDependencyDir.ts).

So starting in RN 0.70 (where the 9.0 series CLI will be consumed) this problem should fix itself. So putting on 0.70.

[jonthysell]

PR #10386 addresses a similar issue, where the path to a project really has changed (and isn't just a different symlink target), by updating the path in the solution file, rather than injecting a new path alongside the old path.

So autolinking would still be "needed", but at least after that PR it would still leave a buildable project.

Once we update to the later v9 CLI, then we'll be using the symlink path, and autolinking wouldn't need to update at all.