TypeScript: `compilerOptions.types` not respected when using project references

[mjbvz]

From @OliverJAsh on September 26, 2018 13:23

• VSCode Version: 10.27.2
• OS Version: macOS 10.13.6

Steps to Reproduce:

Full reproduction case

1. Given a tsconfig.json that has project references, where the referenced TS projects specify a custom compilerOptions.types
2. Open a file inside one of the referenced projects

Expected: VSCode should respect compilerOption.types.

Actual: VSCode appears to ignore compilerOption.types.

For example, I have three TS projects:

• tsconfig-src.json which should not have jest types (compilerOption.types is set to [])
• tsconfig-tests.json which should have jest types (compilerOption.types is set to ["jest"])
• tsconfig.json which references both of the above

The following file is part of the tsconfig-src.json project:

// src/sum.ts

test('foo', () => {})
// Expected: error in VSCode and when running `tsc -b`
// Actual: no error in VSCode, error when running `tsc -b`

export function sum(a: number, b: number) {
  return a + b;
}

When I run tsc -b -f tsconfig.json, I get the expected error:

src/sum.ts:3:1 - error TS2304: Cannot find name 'test'.

3 test('foo', () => {})
  ~~~~

(test is a global type provided by the jest types.)

However, VSCode has no error. Instead, the types appear to be available, even when they shouldn't:

You can try this for yourself with the provided full reproduction case.

Copied from original issue: microsoft/vscode#59466

[mjbvz]

From @OliverJAsh on September 26, 2018 14:26

Actually, this might not be confined to compilerOptions.types. I've also noticed other compiler options like noImplicitReturns are not respected.

[mjbvz]

This is caused by src/__tests__ being placed in the inferred project, instead of the tsconfig project it belongs to. Here's the tsserver.log and relevant project section:

Info 125  [11:15:0.406] Project '/dev/null/inferredProject1*' (Inferred) 0
Info 125  [11:15:0.406] 	Files (21)
    /Path/jest-ts-project-references/node_modules/typescript/lib/lib.es5.d.ts
    /Path/jest-ts-project-references/node_modules/typescript/lib/lib.es2015.d.ts
    /Path/jest-ts-project-references/node_modules/typescript/lib/lib.es2016.d.ts
    /Path/jest-ts-project-references/node_modules/typescript/lib/lib.dom.d.ts
    /Path/jest-ts-project-references/node_modules/typescript/lib/lib.dom.iterable.d.ts
    /Path/jest-ts-project-references/node_modules/typescript/lib/lib.webworker.importscripts.d.ts
    /Path/jest-ts-project-references/node_modules/typescript/lib/lib.scripthost.d.ts
    /Path/jest-ts-project-references/node_modules/typescript/lib/lib.es2015.core.d.ts
    /Path/jest-ts-project-references/node_modules/typescript/lib/lib.es2015.collection.d.ts
    /Path/jest-ts-project-references/node_modules/typescript/lib/lib.es2015.generator.d.ts
    /Path/jest-ts-project-references/node_modules/typescript/lib/lib.es2015.iterable.d.ts
    /Path/jest-ts-project-references/node_modules/typescript/lib/lib.es2015.promise.d.ts
    /Path/jest-ts-project-references/node_modules/typescript/lib/lib.es2015.proxy.d.ts
    /Path/jest-ts-project-references/node_modules/typescript/lib/lib.es2015.reflect.d.ts
    /Path/jest-ts-project-references/node_modules/typescript/lib/lib.es2015.symbol.d.ts
    /Path/jest-ts-project-references/node_modules/typescript/lib/lib.es2015.symbol.wellknown.d.ts
    /Path/jest-ts-project-references/node_modules/typescript/lib/lib.es2016.array.include.d.ts
    /Path/jest-ts-project-references/node_modules/typescript/lib/lib.es2016.full.d.ts
    /Path/jest-ts-project-references/src/sum.ts
    /Path/jest-ts-project-references/src/__tests__/sum.ts
    /Path/jest-ts-project-references/node_modules/@types/jest/index.d.ts

tsc gets the project associations right when run

[sheetalkamat]

At moment this is working as expected since the referenced projects are not loaded as part of file open. Thus since _tests/sum.ts does not belong to tsconfig.json so inferred project is created.

Here we could check if the file belongs to any of the referenced project but that would be additional work on each file open (if file didn't belong to the main project) so we should add this feature with careful thought.
cc: @RyanCavanaugh Another instance of need to unload/load project on demand (if/when we do this)

[joeywatts]

Ran into this issue and having trouble working around it. I thought I'd describe our use case here to both bump this issue and see if there's any solution that might work for us.

Our runtime loads special JS/TS files from a flat file structure which have specific globals available within their file scope. I'll call these "entrypoint" files. Entrypoints are not allowed to "export" things. They run in their own scope. Each entrypoint must define an initialization function called "init" in the file scope. It is very often the case that a project has multiple of these files. The TypeScript compiler recognizes these files as script files instead of modules. The consequence of this is that TypeScript sees multiple declarations of the same identifier (ex: for the initialization function) in the same scope (the global scope is shared across the script files in the same project) and emits a compiler error.

An idea for a possible solution is to separate the compilation of each of these entrypoint files so that we have more control over what's included in each compilation. The compiler provides us a way to do this efficiently with project references. We can separate each of the entrypoints into their own TypeScript project and put all of the standard ES modules into a separate project that can be referenced from each of the other projects.

As an example, if we have entrypoint1.ts and entrypoint2.ts, we'd create tsconfig.entrypoint1.json and tsconfig.entrypoint2.json. Then if our project has other ES modules (module1.ts, module2.ts, etc), we can create a tsconfig.modules.json and add a project reference to this from the entrypoint projects. Then we have a "solution" tsconfig.json at the root which has references to all of these.

Notice how this graph is created:

              modules
             /      \
    entrypoint1     entrypoint2

entrypoint1 and entrypoint2 depend on modules, but neither is included in the other's compilation, so the declarations in entrypoint1 shouldn't conflict with those in entrypoint2. This all works fine and when running tsc here, we get no errors! Unfortunately, while testing this out, I ran into this issue with the tsserver. It doesn't seem to respect project references as tsc does. While I've confirmed that setting up a project like this works perfectly fine when compiling with tsc on the command line, VSCode treats each file as if it doesn't have an associated tsconfig at all... This idiosyncrasy between tsserver and tsc makes project references effectively unusable for us.

It currently seems like there is no way to solve this problem with the following constraints:

• no export
• consistent behavior between language server and compiler
• no change to the file structure of the original projects

[sheetalkamat]

#37239 should help with this