tsconfig.json as higher priority in Visual Studio

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

Mohamed Hegazy (@mhegazy)

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?

Mohamed Hegazy (@mhegazy) and Paul van Brenk (@paulvanbrenk) can correct me if I'm wrong.

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.

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.

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.

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.

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

Paul van Brenk (@paulvanbrenk)

Thanks Paul van Brenk (@paulvanbrenk)!!! looking forward to it!

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

This may be an obvious point, but if I have a developer add a .ts file in Visual Studio, will it go into both the .csproj and tsconfig.json files? Or will Visual Studio have a visual way to show the contents of the tsconfig.json file?

Or, are we saying that, when someone is using tsconfig.json file for web project, they should not add .ts files to Visual Studio at all, but only add them to tsconfig.json?

I'm not necessarily saying that any of these options is preferred nor that they are invalid. But curious if there's been discussion about various common workflows.

We expect most users to not explicitly add ts files to their tsconfig.json file, but depend on the logic in the compiler to automatically pull in all .ts files. This way they would just add them to Visual Studio.

You will still be able to see the compiler context for the tsconfig.json file using the Virtual Project option. If there's a lot of feedback we can decide to make changes later, but for now we want to focus on the most common scenario.

Paul, thank you. I'm trying to figure out how I'll be able to use this feature in the future to solve a problem that I have right now that forces me to abandon the TS build step altogether from within Visual Studio and issue tsc.exe commands directly from the "pre-build" step from the web project (via a batch file). Ugly, but I don't have another solution. The issue that I'm talking about is documented here: #5448 -- I suggest looking at the specific comment which starts with the text "The following is what I hope to be a better explanation of the issue that I'm facing". I believe 5287 and 4714 will address my use-case indirectly.

Because neither feature request directly address my use case, I'm trying to put the pieces together now to see how it will work. That way, if there's some subtle thing that I need, I can contribute to the discussion as the features get implemented.

kasajian (@kasajian)

kasajian (@kasajian) I think the multiple tsconfig.json support will do exactly what you want.

cool. So how would that work? Like, would I specify in Visual Studio which tsconfig file a particular .ts file is associated with?

You use the files property, as discussed here: https://github.com/Microsoft/TypeScript/wiki/tsconfig.json

Okay, then I'll circle back to what I said previously to which you responded "We expect most users to not explicitly add ts files to their tsconfig.json file, but depend on the logic in the compiler to automatically pull in all .ts files. This way they would just add them to Visual Studio."

So then it goes to reason that using the Visual Studio UI to add files to the project is really only useful in the case there's only a single tsconfig.json file. Alternatively, the user will have to add .ts files to both the Visual Studio project and the tsconfig.json file.

To me, the story isn't very clear, and I realize that may be because we simply haven't thought through that far ahead. I'm just trying to wrap my head around the user workflow for the user who wants to do what I indicated in 5448.

thank you.

Or you could do something like this

/app-root
  /admin
    /tsconfig.json << no files property, pulls in admin.ts
    /admin.ts << automatically included
  /play
    /tsconfig.json << no files property, pulls in play.ts
    /play.ts

beautiful

Support for multiple tsconfig.json files is part of 1.8, as is support for more project types.

Not quite fixed - still some cases not covered:
#7044

Navigation Menu

Repository navigation

tsconfig.json as higher priority in Visual Studio #5287

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

tsconfig.json as higher priority in Visual Studio #5287

Description

Activity

DanielRosenwasser commented on Oct 16, 2015

paulvanbrenk commented on Oct 16, 2015

mhegazy commented on Oct 26, 2015

ffMathy commented on Nov 17, 2015

paulvanbrenk commented on Nov 17, 2015

ffMathy commented on Nov 17, 2015

AbubakerB commented on Nov 17, 2015

ffMathy commented on Dec 7, 2015

kasajian commented on Dec 10, 2015

paulvanbrenk commented on Dec 10, 2015

kasajian commented on Dec 11, 2015

paulvanbrenk commented on Dec 11, 2015

kasajian commented on Dec 11, 2015

paulvanbrenk commented on Dec 11, 2015

kasajian commented on Dec 11, 2015

paulvanbrenk commented on Dec 11, 2015

kasajian commented on Dec 11, 2015

paulvanbrenk commented on Jan 26, 2016

oising commented on Feb 12, 2016

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions