Inspect all possible module paths when looking for the best one to create a specifier with #25850
Conversation
| return styles; | ||
| } | ||
|
|
||
| // @link: tests/cases/compiler/Folder/node_modules/styled-components -> tests/cases/compiler/Folder/monorepo/package-a/node_modules/styled-components |
There was a problem hiding this comment.
It looks like some tests use @link and some use @symlink, do you know why?
There was a problem hiding this comment.
@symlink links the below file to another filepath. @link links one place (like a folder) to another - like an ntfs junction.
@link is strictly more powerful - I added it because @symlink couldn't be used to repro the issues I was seeing.
| @@ -194,7 +194,12 @@ namespace ts.moduleSpecifiers { | |||
| const symlinks = mapDefined(files, sf => | |||
| sf.resolvedModules && firstDefinedIterator(sf.resolvedModules.values(), res => | |||
| res && res.resolvedFileName === importedFileName ? res.originalPath : undefined)); | |||
| return symlinks.length === 0 ? getAllModulePathsUsingIndirectSymlinks(files, getNormalizedAbsolutePath(importedFileName, host.getCurrentDirectory ? host.getCurrentDirectory() : ""), getCanonicalFileName, host) : symlinks; | |||
| const cwd = host.getCurrentDirectory ? host.getCurrentDirectory() : ""; | |||
There was a problem hiding this comment.
I'm not sure I follow all the logic here, but there may be some duplicated effort. A few lines above this we get symlinks, then in discoverProbableSymlinks there is some nearly identical (copy-pasted?) code to do the same thing.
There was a problem hiding this comment.
As far as I know, it's not duplicated at all. Here we find files whose realpath differed from their actual path, provided those files refer to the imported file. In discoverProbableSymlinks, we crawl all files looking for common parts among all files with symlinks to find probable directory junction links. If I remember correctly, anyway.
|
@weswigham can you also port to release-3.0 |
…eate a specifier with (microsoft#25850) * Inspect all possible specifier paths when looking for the best one * Add missing secondary option from test
This allows us to look at both the real and (potentially multiple) symlink paths available for a module and choose the one that gives the "best" specifier from among all of them (since a symlinked path isn't always the best one!).
In the case of the linked issue, we were finding a symlink from the other module that was symlinked into the project we were compiling, causing us to forgo both the real path (which would give us a nice global specifier) and the project-local symlink path (which would also yield a global specifier).
Fixes #25511.
Also fixes a bug in our test harness where symlinks and json files weren't carried over into the
.d.tsvalidation build, which was causing some unnecessary.d.tserror baselines.