Only resolve symlinks in node_modules

[ghost]

Fixes #10364 and fixes #9552.
This is based on #11993 and will be rebased onto master once that is merged.

Based on the issues I've seen, the best heuristic to decide whether to resolve a symlink is whether it comes from node_modules. So we now do not resolve symlinks for ordinary files. (This is a breaking change.)

The change to moduleNameResolver is simple. However, our test harness did not accurately reflect what the command line compiler really did, so I had to change how it treated symlinks. I've tested the new tests with the command line compiler as well; instructions for doing so are at the bottom of each test file.

[RyanCavanaugh]

@dotnet-bot test this please

[mhegazy]

I thought we were not going to resolve symlinks in resolveModuleNames at all, so what is the reason for the change of strategy?

[mhegazy]

you need to do the same for resolveTypeReferenceDirectives as well.

[vladima]

don't think that changes in the way how common subpath is computed should not be the part of this PR since it is not related to original issue

[ghost]

Review #11993, then I'll rebase.

[devedse]

Can/will this fix be included in the next release of TypeScript (2.0.10)?

[mhegazy]

Yes it will be included in the next release; and the next release is TypeScript 2.1.3 (and not 2.0.10).

[timocov]

I thought we were not going to resolve symlinks in resolveModuleNames at all, so what is the reason for the change of strategy?

@andy-ms whether did you remember why? Could you please try to remember the reason or what can happen if provide undefined (or path => path) as CompilerHost.realpath to ts.createProgram?

[ghost]

I think this was just the simplest place to do the resolving.
If the host doesn't define realPath, it's treated the same as path => path. In both cases, it means the compiler will always see a symlink as a different file from the original; since it can't resolve the symlink, it has no way of knowing they're the same file. See function realPath in moduleNameResolver.ts.

[timocov]

@andy-ms Thank you for clarification!

it has no way of knowing they're the same file

What can happen in this case except getting multiple SourceFile instances for one real file but for each symlink (and, possibly, increasing memory usage or compilation time)? How it can affect on compilation?

[ghost]

In that case it will be just like you had to separate files with no symlink. It could cause compile errors if the file contained a class with a private member, since a class instance coming from one file won't be assignable to the other file's class. E.g.:

foo/index.d.ts:

export class C { private x: number; }

user.ts:

import { C as C1 } from "foo";
import { C as C2 } from "other/foo";

const c: C1 = new C2(); // Error

[timocov]

Oh, I get it. Thank you!