Typescript: Project References don't resolve ambient Definitions

[LucaVazz]

TypeScript Version: 3.3.0-dev.20181213

Search Terms:
Project References
Composite Project
Ambient Definitions

Code
(minimum example, see repository link below for complete setup)
tsconfig_base.json

{
  "compilerOptions": {
    "target": "es5",
    "module": "none",
    "declaration": true,
    "declarationMap": true,
    "sourceMap": true,
    "strict": true,
    "composite": true
  }
}

utils/tsconfig.json

{
  "extends": "../tsconfig_base.json",
  "include": [
    "*.ts",
    "*.d.ts"
  ]
}

utils/utils.d.ts

declare function leftPad(s: string, n: number): string;

converter/tsconfig.json

{
  "extends": "../tsconfig_base.json",
  "include": [
    "*.ts",
    "*.d.ts"
  ],
  "references": [
    { "path": "../utils" }
  ]
}

converter/length.ts

function formatInches(i: number) {
    if (i < 12) {
        return `${i}"`;
    }
    const ft = Math.floor(i / 12);
    i = i - ft * 12;
    return `${ft}' ${leftPad(i.toString(), 2)}`;
}

Expected behavior:
Running tsc -b converter compiles successfully.

Actual behavior:

tsc -b converter --verbose
[13:10:29] Projects in this build:
    * utils/tsconfig.json
    * converter/tsconfig.json

[13:10:29] Project 'utils/tsconfig.json' is up to date because newest input 'utils/moreUtils.ts' is older than oldest output 'utils/moreUtils.js.map'

[13:10:29] Project 'converter/tsconfig.json' is out of date because output file 'converter/length.js' does not exist

[13:10:29] Building project '[...]/converter/tsconfig.json'...

converter/length.ts:18:22 - error TS2304: Cannot find name 'leftPad'.

18     return `${ft}' ${leftPad(i.toString(), 2)}`;
                        ~~~~~~~


Found 1 error.

(Local paths redacted)

As a side note, when compiling the packages into outFiles the compilation works just fine.
(This can be seen in @RyanCavanaugh's example repository from which mine is forked / when reverting to commit 0f66d20 of my example repository.)

Playground Link:

Example Repository:
https://github.com/LucaVazz/ts-project-references-for-ambient

Related Issues: #22997 #25600 #26595 #26689 #26867

[LucaVazz]

I'm aware that a work-around (as proposed in https://stackoverflow.com/a/53550493 ) is possible:
Adding "../utils/*.d.ts to the include-array in converter/tsconfig.json resolves the issue.

However I hope there is a cleaner, automatic way to include the (ambient) definitions of referenced projects when using the build-mode of the compiler.

[sheetalkamat]

Currently we only include the out.d.ts if referencedProject has --out or --outFile but we need to handle non module resolution and --out is not specified.

[LucaVazz]

okay, thanks for confirming my suspicion.

Is it planned to enable the use as described here in the near future?

[sheetalkamat]

Adding @DanielRosenwasser Since we would need to discuss and decide what needs to happen here. It is yet to triaged and added to any milestone.

[DanielRosenwasser]

@RyanCavanaugh did a lot of thinking around these scenarios; I'd say let's wait on him to get back first.

[NoelAbrahams]

@sheetalkamat, how does your fix work with outDir? I'm very interested in testing your fix in Visual Studio 2017. Is there a way for me do do that?

[sheetalkamat]

It does work with or without outDir since it adds all the declaration outputs into the source tree if the module resolution is not set.

@amcasey would know how to update to use the drop from this branch with VS 2017

[amcasey]

@NoelAbrahams You'll want to run a command like this from the Developer Command Prompt for the instance of VS you want to test:

vsregedit set "%VSINSTALLDIR%." HKCU TypeScriptLanguageService CustomTSServerLocation string "full path to tsserver.js"

Revert with

vsregedit remove "%VSINSTALLDIR%." HKCU TypeScriptLanguageService CustomTSServerLocation

NOTE: This only affects the Language Service, not the command-line build.
NOTE: The regkey takes precedence over any project-level settings.

[NoelAbrahams]

@amcasey that's useful to know. But I think I need to get this working via the standard project build (MSBUILD) in Visual Studio in order to test it meaningfully. We have a setup where Project B depends on the output of Project A and I want to see how this fix works. At the moment (even with "project references") we still need to add <reference> tags to the output of Project A from Project B in order to make the types visible in Project B.

I can only test this if MSBUILD works.

[amcasey]

In that case, it's probably easiest to back up your TypeScript folder and replace the contents with those from the new build.

[NoelAbrahams]

@sheetalkamat is there any chance you could send me a zip of your build to replace in C:\Program Files (x86)\Microsoft SDKs\TypeScript\3.3?

We've been working on migrating a large Visual Studio solution to use project references. It's looking pretty good, but there is a bug in here somewhere (or something is wrong with our configuration) that is preventing the projects from building in the right order. The build order at the moment seems to be totally random, which causes multiple errors when rebuild is run on the Visual Studio solution.

We've done the following:

• Add <TypeScriptBuildMode>true</TypeScriptBuildMode> to all projects.
• In tsconfig:
  
  
  
  • Add "composite": true for projects that are referenced by other projects.
  
  
  • This also requires declaration to be set to true
  
  
  • Add "declarationMap" for projects that are referenced by other projects.
  
  
  • Update the "references" array in client projects to reference the "library projects"
  
  
• Remove Visual Studio inter-project build dependencies so that the build can be orchestrated by TypeScript alone.

We still have a custom build step we have for concatenating .d.ts files for "library projects" so that they can be referenced in "client" projects downstream using <reference> tags.

We want to eliminate this step so that we can rule out one more moving part in the project references configuration.

I just want to investigate whether your fix changes anything before opening a new issue.

Hope this makes sense. My email is to be found on my profile page on GitHub.

Many thanks!
Noel

[sheetalkamat]

@LucaVazz I had chat with @RyanCavanaugh and it was discussed that we wont be including your input ".d.ts" file anytime in the referencing projects. So your repro code as is not going to work and its going to error even with the fix. The work around for that is to move those to ",ts" files instead and let the ".d.ts" be generated in output folder.
The fix that I am going to do is to include output "*.d.ts" files from non module compilations without --out will be included in your referenced project as there is no other way to refer to those.

[NoelAbrahams]

@sheetalkamat tried out the 3.4RC and this is working brilliantly. Thanks

[tdaffin]

Yes, thanks for this fix. It would also be very helpful if there was a section in the project references documentation describing this use case.

I've been working on migrating a large number of TypeScript files from a monolithic MSBuild based system into a multi-project setup, and I can imagine that others in a similar position might run into this.

Perhaps adding a section right after https://www.typescriptlang.org/docs/handbook/project-references.html#msbuild would be relevant.

Perhaps something like:

Project Reference Usage without module imports

If your projects are not using module imports it is necessary to set the 'module' compiler option to 'none' in your composite projects so that projects that depend on them can find their emitted declarations at compile time:

"compilerOptions": {
    "module": "none", // Have to set module to none so that we can depend on this project as a non-module project
    "composite": true, // Mark this as a composite project so that other projects can depend on it
    "declaration": true, // A composite project must create d.ts files for other projects to reference
    "declarationMap": true, // Enable use of editor features like 'Go to Definition' and Rename to transparently navigate and edit code across project boundaries in supported editors.
    "outDir": "../built"
  }