External module resolution #3325
Conversation
… map stored in SourceFile
Proof of concept for module resolution via mapping file(s). Includes limited test coverage, no caching, and generally pretty crappy code. If the spec for this feature lands on something near this PR I don't mind fixing it up, though I don't know how to write idiomatic TSC code so the PR will still likely need some maintainer love. NOTE: Currently only supports references within the project root directory. Since dependencies managed by a package manager are likely to sit *outside* of the project root directory this solution falls apart a little bit. Unfortunately, I am not sure how to find a mapping file that is shipped with third party modules. This is particularly important for dependencies that have dependencies.
|
Hi @Zoltu, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution! TTYL, MSBOT; |
|
@Zoltu, Thanks for signing the contribution license agreement so quickly! Actual humans will now validate the agreement and then evaluate the PR. |
|
Sorry for the delay. this should be now handles by #3147, #4154, and #4352. The change was mainly on the tooling side of the house, with VS and tsserver needing to handle resolution correctly; the previous desing had resolution responsibility split between the compiler/LS and the LS host (VS/tsserver). so that made it a bit hard to collaborate on this change. With TS 1.6, @vladima has consolidated all module resolution logic in the program, so there should be minimal host interaction into resolution, and in the future we should be able to accept similar changes without any work on the host side. Thanks again and sorry for the delay. |
Fixes #2338 ... at least half of it.
TL;DR: See last commit, ignore others.
Note: This is branched off of #3324 and has Microsoft/TypeScript#externalModuleResolution rebased on master underneath it since that seemed to be relevant for this change. It also has some jake commands added for ease of testing. If this PR nears approval, I will clean it up as desired by maintainers. In the meantime, check the last commit for the meat of the PR.
Summary
Adds support for module resolution via a mapping file.
This is a proof of concept for module resolution via mapping file(s). Includes limited test coverage, no caching and poor factorization. If the spec for this feature lands on something near this PR I don't mind fixing it up, though I don't know how to write idiomatic TSC code so the PR will still likely need some maintainer love.
CAVEAT
Currently only supports references within the project root directory tree. Since dependencies managed by a package manager are likely to sit outside of the project root directory tree this solution falls short of achieving full desired results. Unfortunately, I am not sure how to find a mapping file that is shipped with third party modules (outside the project root tree) since I can't walk up the directory tree indefinitely, and it is undefined how far up is a reasonable distance to walk.
This is particularly important for dependencies that have dependencies since one can reference a dependency outside of the tree with a mapping file but that dependency can't have a mapping file of its own up its directory tree. This means that dependencies would have to either have relative file paths (no mappings) or they would need to use whatever you have defined in your project's mapping file(s). In the first case, this hurts library distribution because dependency managers have to do the terrible NPM thing of having every dependency have its own node_modules folder. In the second case, this just leads to broken apps when you cause a dependency to use a mis-matched version of one of its dependencies.