tsconfig.json as higher priority in Visual Studio

[AbubakerB]

Hey guys,

A question, what is the reason as to why a project file supersedes a tsconfig in Visual Studio? (#4820 comment)

I'd assume that as soon as I introduce a tsconfig.json at any sub-directory level, that tsconfig.json should override the typescript compilation options for that level and below, unless another tsconfig exists within.
That's what makes most sense to me.

Is there a specific reason as to why the current method doesnt work like that?
The action of me adding a tsconfig.json in a project specifically means, i want to override the compilation options, right?

Project(MVC5) / file.ts --> file.ts should use default project TS options
Project(MVC5) / scripts / tsconfig1.json
Project(MVC5) / scripts / file2.ts --> file2.ts should use tsconfig1 options
Project(MVC5) / scripts / framework / tsconfig2.json
Project(MVC5) / scripts / framework / file3.ts --> file3.ts should use tsconfig2 options

Thanks for your time

[DanielRosenwasser]

I think the intuition is that a project file is a more committed/custom solution that the user has in mind. After all, if you have a project file, why wouldn't you just set your compilation settings there?

@mhegazy and @paulvanbrenk can correct me if I'm wrong.

[paulvanbrenk]

tsconfig.json should have higher priority, since we should default to code sharing across editors. The Project properties in VS need updating to reflect that thinking, but the current implementation should work that way.

[mhegazy]

Also note, we will need a way to switch off/on compile-on-save for projects managed by tsconfig.json. compileOnSave property at the top level is what atom-typescript uses and seems like a good option. see #2326 for more details.

[ffMathy]

Any updates on this? Is it still going to be part of Typescript 1.8? I rely on it heavily. I can't continue development until it is fixed.

[paulvanbrenk]

Yes, there is still work planned here for 1.8.

However looking at your project.. I don't think this will work as you expect. The tsconfig.json support will always override the project settings.. and once you introduce a tsconfig.json file we'll ignore all .ts files which are not part of a tsconfig.json scope.

Further we won't support nested tsconfig.json files, a tsconfig.json context will contain all files in it's cone. Further the naming of tsconfig.json is prescriptive... tsconfig1.json will not work. (I'm assuming your sample uses that as an illustration).

So for your project this results in the following compilation contexts:

Project(MVC5) / file.ts
Project(MVC5) / scripts / tsconfig.json (1)
Project(MVC5) / scripts / file2.ts
Project(MVC5) / scripts / framework / tsconfig.json (2)
Project(MVC5) / scripts / framework / file3.ts

tsconfig.json (1) will create an output containing the code from both file2.ts and framework/file3.ts.
tsconfig.json (2) will create an output containing the code from framework/file3.ts.

If you want to separate file2 and file3, you'll have to put them in 2 sub-directories of scripts.

Project(MVC5) / scripts / app / tsconfig.json (1)
Project(MVC5) / scripts / app / file2.ts
Project(MVC5) / scripts / framework / tsconfig.json (2)
Project(MVC5) / scripts / framework / file3.ts

Also this currently works in the language service, but the only way to compile this is to use a grunt/gulp pipeline.

[ffMathy]

That sounds brilliant to me. Exactly as I want it. Explicit and minimal.

[AbubakerB]

Thanks @paulvanbrenk!!! looking forward to it!

[ffMathy]

Great work on this. Now I can't wait!