I just tested TS 3 RC project references in a typical npm package setup with included tests. The tests were set up as a TS project referencing the implementation TS project.
I surprisingly found that project references do not adhere to the outDir compilerOption of _referenced_ or _referencing_ projects, and that the relative paths for module imports in the compiled referencing project's JS files therefore are wrong; paths point to the TS folder, not the compiled output folder.
A somewhat simplified view of my PoC:
Expected behavior:
Relative paths of module imports in the compiled code for the referencing project should be calculated from:
I put up a small repository to demonstrate the problem:
https://github.com/josundt/tsprojects-outdirproblem
PS! I also added this request under the general discussion thread on https://github.com/Microsoft/TypeScript/issues/25600
Still hoping for the prioritization of this in 3.1, even if I could not see anything indicating so in the 3.1 RC release notes. Testing the sample project in the earlier mentioned repository with 3.1 RC still does not work as expected.
My findings indicate that project references in v3.0 can only be used with TS projects that output compiled JS to same folder as TS source code.
This makes project references applicable to only a subset of the solutions I develop, and I can't see any logical reason for this limitation; I assume it is just a token of the "project references" concept's maturity level in v3.0, and that the concept will evolve and become more robust going forward, also support what I am asking for.
.
Thanks. Looking forward to test this 馃槂
Still this has not been fixed in 3.1.1.
Import paths in emitted JavaScript are wrong when outDir compiler option is set (when set to something different than the TypeScript source directory).
This fails when using outDir both in the _referencing_ or/and in the _referenced_ project.
I see no reason why this cannot be fixed.
I suggest that the issue is reopened, or I will have to create a new issue.
we do not transform module specifiers in output javascript in any condition. We always recommend to use the module specifiers that you intent to use at runtime and then help compiler with that resolution at design time by providing appropriate options
I am not entirely sure what would be the easiest way to help compiler at design time. Would you be able to show some example, f.ex. based on the structure in my repo https://github.com/josundt/tsprojects-outdirproblem ?
Refer to this documentation of compiler options for module resolutions. From your example i cant make out what you want to do. In both src and test directory there are two tsconfig files so not sure which one you are looking at. Can you please edit the example so as to you have set options you want. And I can then look at it.
I just came across the same thing in version 3.3.3. I have yarn workspaces with the following setup:
packages/
api/
cli/
src/
tsconfig.json (composite build that references "../common")
common/
tsconfig.json (composite build referenced by "../cli")
Unfortunately when building packages/cli/ I get a bunch of .js and .d.ts crap leftover in packages/common/. And using outDir in packages/common/tsconfig.json doesn't work with my packaging script :/
Most helpful comment
I just came across the same thing in version 3.3.3. I have yarn workspaces with the following setup:
Unfortunately when building
packages/cli/I get a bunch of.jsand.d.tscrap leftover inpackages/common/. And usingoutDirinpackages/common/tsconfig.jsondoesn't work with my packaging script :/