Repository navigation
TypeScript: compilerOptions.types not respected when using project references #27372
Description
From Oliver Joseph Ash (@OliverJAsh) on September 26, 2018 13:23
- VSCode Version: 10.27.2
- OS Version: macOS 10.13.6
Steps to Reproduce:
- Given a
tsconfig.jsonthat has project references, where the referenced TS projects specify a customcompilerOptions.types - 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.jsonwhich should not havejesttypes (compilerOption.typesis set to[])tsconfig-tests.jsonwhich should havejesttypes (compilerOption.typesis set to["jest"])tsconfig.jsonwhichreferencesboth 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
Activity
mjbvz commentedon Sep 26, 2018
From Oliver Joseph Ash (@OliverJAsh) on September 26, 2018 14:26
Actually, this might not be confined to
compilerOptions.types. I've also noticed other compiler options likenoImplicitReturnsare not respected.mjbvz commentedon Sep 26, 2018
This is caused by
src/__tests__being placed in the inferred project, instead of thetsconfigproject it belongs to. Here's the tsserver.log and relevant project section:tscgets the project associations right when runsheetalkamat commentedon Sep 26, 2018
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: Ryan Cavanaugh (@RyanCavanaugh) Another instance of need to unload/load project on demand (if/when we do this)
Move test `tsconfig.json` files under `__tests__` to support editors
Move test `tsconfig.json` files under `__tests__` to support editors
joeywatts commentedon Dec 20, 2019
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.tsandentrypoint2.ts, we'd createtsconfig.entrypoint1.jsonandtsconfig.entrypoint2.json. Then if our project has other ES modules (module1.ts,module2.ts, etc), we can create atsconfig.modules.jsonand 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:
entrypoint1andentrypoint2depend onmodules, but neither is included in the other's compilation, so the declarations inentrypoint1shouldn't conflict with those inentrypoint2. This all works fine and when runningtschere, 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 astscdoes. While I've confirmed that setting up a project like this works perfectly fine when compiling withtscon 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:
exportsheetalkamat commentedon Mar 10, 2020
#37239 should help with this
Move test `tsconfig.json` files under `__tests__` to support editors