buildOnSave support in tsconfig.json

[johnnyreilly]

As discussed compileOnSave support in tsconfig.json is due to ship with TS 1.8.

However compileOnSave is just for stopping compiling on save as I understand. Are there plans to support for buildOnSave as well?

My use case is this:

I have a web app which has been built using TypeScript (since TS was 0.9!) The older part of the codebase works and uses global scope with namespaces and is written in ES5. The newer part of the codebase is written using ES6 / modules and is compiled using Webpack with ts-loader and babel-loader.

Each part of the code base is driven by a separate tsconfig.json; however - deactivating the Visual Studio build by adding <TypeScriptCompileBlocked>true</TypeScriptCompileBlocked> to the .csproj (see here) is an all or nothing affair.

So if I turn it off I have to manually run tsc against the old code in order that it is generated. Do-able but clunky. It'd be nice to be able to control both build and file level compilation from tsconfig.json

[mhegazy]

A few notes, CompileOnSave (in VS 2015) already compiles all files in your project. We have no plans of supporting a watch mode in VS, tsc --w should be sufficient, as well as existing build tool integration.

Since you have other build steps, i am assuming you have some build system already wired in, so why not just use a watch capability in your build system. like gulp watch for instance?

Also, why not just put "compileOnSave": "true" in your older portion of the project, "compileOnSave": "false" in the newer portion?

[johnnyreilly]

Hi @mhegazy,

Are you saying that having compileOnSave set to false will effectively act as a <TypeScriptCompileBlocked>true</TypeScriptCompileBlocked> scoped to the tsconfig.json? So this would block TypeScript compilation triggered as part of a Visual Studio build? If so that's awesome!

For now we've been deactivating all compilarion with <TypeScriptCompileBlocked>true</TypeScriptCompileBlocked> and triggering 2 separate TypeScript compile tasks in our csproj. One (the old stuff) invokes tsc -p Scripts and the other (the new stuff) invokes a gulp task which triggers WebPack and some other bits and pieces.

Rather quirkily we're having to include to nuget TypeScript target in the csproj in order that Visual Studio doesn't come along and re-add the standard TypeScript target to the project and ask us if we'd like to search Definitely Typed for typings.

I'm just looking for VS to be a straight TypeScript editor really. However it's not easy. It feels like you have to "trick" the tooling into doing what you want.

BTW we are using watch modes when we're running in debug (not triggered as part of the vs build though)

[johnnyreilly]

PS apologies for typos - this is being written on my phone as I walk to work on a cold winter day. Fingers a bit numb!

[mhegazy]

Are you saying that having compileOnSave set to false will effectively act as a true scoped to the tsconfig.json? So this would block TypeScript compilation triggered as part of a Visual Studio build? If so that's awesome!

that is not the case. I miss understood your original post. sorry about that. the "onSave" part through me off. i think i understand the issue now. let me reiterate it to confirm, you want to have a way to not build a tsconfig.json when you have multiple tsconfig.json in one project.

if so, i think you can do this by excluding the tsconfig.json from your project. the MSBuild targets enumerate them from the project. we can add a property on the item to "ignore" it, as well.

I'm just looking for VS to be a straight TypeScript editor really. However it's not easy. It feels like you have to "trick" the tooling into doing what you want.

The tools look for a property <TypeScriptEnabled> in your project file. including the default targets sets this property for you. if the property is set, that indicates that this is a "TypeScript project" (some expectations are made here, that you have one build target, and that you are not customizing the build, no external tools etc..); from your description this does not seem to be the case. and if i am correct, you already have your build wired correctly. so what you need is to set this property to false. The language service will treat the files in your project as "loose files", i.e. will forget about the project, since you have tsconfig.json, things should work as expected.

give TypeScriptEnabled a try and let me know how it goes.

[johnnyreilly]

Thanks for the input @mhegazy - I'll give it a try tomorrow.

[johnnyreilly]

Hi @mhegazy,

Didn't work I'm afraid. Removing tsconfig.jsons from the csproj and setting <TypeScriptEnabled>false</TypeScriptEnabled> started the project treating the 2 separate codebases as a single TypeScript context and ignored the tsconfig.jsons entirely.

So it looks like the ability to control overall build from tsconfig.json doesn't exist in Visual Studio at present.

Also, it's necessary to have TypeScript targets in your csproj if you want to use Visual Studio as an TypeScript editor in use cases where there are multiple tsconfig.jsons. However <TypeScriptCompileBlocked>true</TypeScriptCompileBlocked> will need to be set if you're doing your compilation outside of VS.

[johnnyreilly]

Hey @mhegazy,

Since I had a rather tricky time getting my workflow up and running in Visual Studio I decided to write it up in case others are in a similar spot. It can be found here: http://blog.johnnyreilly.com/2016/02/visual-studio-tsconfigjson-and-external.html

If I'm offering any bad advice then do feel free to set me straight. Corrections are always welcome 😄

For what it's worth I've got a workflow that seems okay. I think the number of hoops that had to be jumped through is a shame but I'm glad that using Visual Studio for more than vanilla TypeScript scenarios now seems to be possible. I think it could really benefit from being easier though.

[mhegazy]

so why not split your project into two projects instead?

[johnnyreilly]

They're part of the same app / website. To split into other projects would mean 2 websites and extra complexity. Also, in the end I want to unify the compilation approach and go all in on ES6 / modules. This is a short term measure until time allows.

[johnnyreilly]

Although did you mean 2 TypeScript projects rather ASP.Net MVC projects? It's effectively 2 TypeScript projects inside a single ASP.Net project as denoted by the 2 separate tsconfig.jsons