Problem markers not updated across multiple tsconfig.json

[lorenzodallavecchia]

The TypeScript IDE builder seems not capable of reporting problems on files that are part of the source a tsconfig.json project but influenced by the changes in the sources of a different tsconfig.json.

My original scenario is one with multiple Eclipse projects, each containing a tsconfig.json and depending on each other, e.g. because one exposes a method that the other one uses.
Suspecting a problem with building across multiple Eclipse project, I have tested the scenario with multiple tsconfig.json files in the same Eclipse project. The problem remains.
For both scenarios I have enabled both Compile on Save and Build on Save.

Steps to Reproduce

1. Import all the Eclipse projects from this ZIP file.
2. Ensure the Build Automatically is enabled. Note that no error markers appear on the files or in the Problems view.
3. First scenario Open the multi-poject-a/src/calculator.ts file and add a private modifier to the sum method. Save.
4. The project builds. An error is reported on multi-project-a/src/main.ts and that is correct. However, multi-project-b/src/main.ts should also be marked but is not. If you try to open the latter file, the editor will correctly annotate the error.
5. Second scenario Open the single-poject-multi-config/a/src/calculator.ts file and add a private modifier to the sum method. Save.
6. The project builds. An error is reported on single-project-multi-config/a/src/main.ts and that is correct. However, single-project-multi-config/b/src/main.ts should also be marked but is not. If you try to open the latter file, the editor will correctly annotate the error.
7. Compare with the working scenario Open the single-poject-one-config/a/src/calculator.ts file and add a private modifier to the sum method. Save.
8. The project builds. An error is reported on both single-project-one-config/a/src/main.ts and single-project-one-config/b/src/main.ts. That is correct.

Rationale

When working on large projects with long dependencies, one should be able to rely on the IDE to notify on the cascading effects of any change. Even if the TS build is done again at integration time, that would still mean making a bad commit just because the IDE did not warn about the problems.

Comparison with VSCode

Interestringly, VSCode behave even worse than TypeScript IDE. In fact, all files must be open to have their errors listed in VSCode own Problems view. There is an open issue for that on VSCode: microsoft/vscode#8201.

[angelozerr]

Thanks @lorenzodallavecchia let me time to study your testcases and I will you give you feedback. The first thing that I can tell you is that I cannot display this error kind when user is typing.

[angelozerr]

@lorenzodallavecchia I cannot find attached ZIP file?

[lorenzodallavecchia]

Woops, sorry. Here it is.
TestProjects.zip

[angelozerr]

@lorenzodallavecchia typescript.java cannot multiple Eclipse projects today. I would like to wait for TypeScript work about this multi project with tsserver command like OpenExternalProjects.

We must understand how to consume those commands to implement this issue.

[lorenzodallavecchia]

Thanks again Angelo.

Actually, I was looking into that problem today and I saw that typescript.java's builder assumes that all input files of a TS project are located in the same folder (or subfolders) relative to the tsconfig.json file.
Since I was trying to go up in the folder structure (e.g. with ../OtherProject), the builder assumes that the file is not part of the tsconfig.json context.

I agree that this is something that TS should support.

In the meanwhile I will probably go with implementing an ad-hoc incremental builder that can meet my use case.

[angelozerr]

I would like to support "compile on save" with tsserver which will improve a lot performance.

But today i'm very busy with tslint integration (with quick fix, etc).

[angelozerr]

@lorenzodallavecchia I have tried your project with new compile on save done with tsserver and the good news is that it works, but you must adjust your tsconfig.json with include to help tsserver.

4. The project builds. An error is reported on multi-project-a/src/main.ts and that is correct. However, multi-project-b/src/main.ts should also be marked but is not.

To fix the problem, update your multi-project-a/tsconfig.json like this:

{
	"compilerOptions": {
		"target": "es5",
		"noEmit": false
	},
	"compileOnSave": true,
	"include": ["**/*", "../multi-project-b/src/**/*"]	
}

6. The project builds. An error is reported on single-project-multi-config/a/src/main.ts and that is correct. However, single-project-multi-config/b/src/main.ts should also be marked but is not.

To fix the problem, update your single-project-multi-config/a/tsconfig.json like this:

{
	"compilerOptions": {
		"target": "es5",
		"noEmit": false
	},
	"compileOnSave": true,
	"include": ["../**/*"]
}

In other words TypeScritpt seems searching referencing ts files from the parent folder where tsconfig.json is hosted. You must to use include to help the search. You can see that by using Ctrl+Shift+G to find references of ts files.

[lorenzodallavecchia]

Hi @angelozerr, I have just tested the project with the new builder at it looks very promising indeed. The performance is also noticeably better, even with such a small set of files.

Adding include for "helping" TS in finding the files looks perfectly reasonable to me. I'm also realizing that the test case may be somewhat incorrect, since I was including files that were outside of the compilation scope of a single tsconfig.
The main concearn for me here is that I have to make the project A refer to project B, while in reality the opposite dependency is true (i.e. project B is the one that "requires" project A to work).
In a practical scenario, "A" could be a shared library that is used by an unknown number of other projects, which makes in impractical to list all of them.

Is it possible that this limitation is caused by the way projects are configured on tsserver? Last week I started studying its behavior and saw that it supports "external projects" as well as an "implicit project". I have not looked into your code in typescript.java, so it is well possible that you are already aware of all this!

I also experienced another issue that is probably not related to this bug at all. When compiling with noEmit set to true, the builder fails with this stack trace.
This is not a big deal since disabling emitted files was just part of the effort to minimize the test case.

[angelozerr]

the builder fails with this stack trace.

Yes I have seen that, it's tsserver error. I don't know how we could improve that?

If you think we can close this issue, please close it. Thanks!

[lorenzodallavecchia]

If you think we can close this issue, please close it.

I was not closing it because of the A -> B dependency which is still a showstopper for me.
However, I agree that 90% of the problem tracked by this issue is fixed. I will close it and open a new one for the dependency issue.

Thanks!

[lorenzodallavecchia]

Opened #140 for tracking the cross-project include problem.

[angelozerr]

Is it possible that this limitation is caused by the way projects are configured on tsserver? Last week I started studying its behavior and saw that it supports "external projects" as well as an "implicit project". I have not looked into your code in typescript.java, so it is well possible that you are already aware of all this!

Don't study a lot that, perhaps it is managed with https://github.com/Microsoft/vscode/blob/master/extensions/typescript/src/typescriptServiceClient.ts#L438 (--useSingleInferredProject) ?

Any contrubution are welcome!

[lorenzodallavecchia]

I investigated both external projects and inferred projects and now the picture is a lot clearer.
There are a number of issues behind the cross-project and cross-config problems, and some of them may even show up with a single project. I will comment on #109 with a complete list.