Different tsconfig lookup behaviour between tsc and tsserver

[dbaeumer]

From @tkrotoff on November 26, 2015 18:37

Context: you can add all your .d.ts files inside tsconfig.json instead of writing /// <reference path="my.d.ts" /> in each .ts file (way better).
It works fine with tsc.

Unfortunately it does not always work with vscode.

Example: https://github.com/tkrotoff/vscode-tsconfig.conf-issue
test/tsconfig.json references files outside its directory and vscode fails while tsc is fine with it.

Copied from original issue: microsoft/vscode#716

[dbaeumer]

@tkrotoff when running tsc in the src directory it will only compile Foo.ts since the tsconfig.json file inside the src directory only lists that file. If you run the tsc command inside the test folder it will use the tsconfig.json from there.

If you open the Foo.spec.ts file we try to find a tsconfig.json file to use. The rule the tsserver uses is to look for the first tsconfig.json file in the parent directory chain. We discussed whether we should have a mapping to tell VSCode which tsconfig.json file to use for which ts file but that seemed unnecessary complicated.

If you move you Foo.spec.ts file into the test folder and update the tsconfig.json file accordingly everything should work as expected.

In general VSCode is using the tsserver from https://github.com/Microsoft/TypeScript and the tsconfig.json lookup behavior is defined in the tsserver. I will move the issue to the TypeScript repository since a fix for this needs to be implemented in the tsserver.

[dbaeumer]

Adjusted the title to reflect the problem in TS land. To reproduce do the following after cloning the example:

• cd test
• tsc -p .

Observe: the Foo.spec.ts file is compiled nicely

Try to open Foo.spec.ts in a editor like Sublime or VSCode. The tsserver always picks the tsconfig.json file in the src directory using its defined lookup rules.

[tkrotoff]

If you move you Foo.spec.ts file into the test folder

This is exactly what I want to avoid :-) I want my tests as close as the code as possible. Instead of separating my code by type of files (controllers, templates, tests, models...), I prefer to regroup files by features/modules (this is very common nowadays).

Example:

src/feature1/model.ts
             model.spec.ts
             controller.ts
             controller.spec.ts
             template.html
             documentation.md
    feature2/model.ts
             model.spec.ts
             controller.ts
             controller.spec.ts
             template.html
             documentation.md
    tsconfig.json

test/tsconfig.json

vs

src/models/feature1_model.ts
           feature2_model.ts
    controllers/feature1_controller.ts
                feature2_controller.ts
    templates/feature1_template.html
              feature2_template.html
    documentation/feature1.md
                  feature2.md
    tsconfig.json

test/feature1_model.spec.ts
     feature2_model.spec.ts
     feature1_controller.spec.ts
     feature2_controller.spec.ts
     tsconfig.json

Anyway, TypeScript/vscode/tsserver should be agnostic about the way code is organized and should not add any limitation.

I will move the issue to the TypeScript repository

Thx

[dbaeumer]

@tkrotoff I already moved the issue to TS. It is #716

[tkrotoff]

@dbaeumer

I already moved the issue to TS. It is #716

You can delete your comment: issue 716 is unrelated. We are already commenting on the TS issue :-) I've quoted you just to thank you.

[zhengbli]

If I understand correctly, this is asking for an API that is similar to "open Project"? For example, if the user can open a project by open a tsconfig.json file directly from VSCode, the aforementioned problems seems to solvable.

This works fine for one-time compilation, but in the server scenario this will cause many problems for us. For example, normally we install one recursive directory watcher at the project root, which detects file addition / removal under the root. Apparently that wouldn't work if your code lives at upper level. Also, what happens if you have another tsconfig.json somewhere in the upper level? The project boundaries become ambiguous.

I think we need delicate design between we are committed to support this scenario.