Add settings for multiple environments in tsconfig.json

[clavecoder]

Suggestion

In order to compile development, test, and production builds as part of a larger pipeline
As a team project build administrator
I want to be able to define different compiler settings for different environments in tsconfig.json

Provide a feature similar to the babelrc file env option so one tsconfig.json file can support multiple environments. It is very cumbersome to have to maintain multiple tsconfig.json just so a few options can differ.

Scenario

For latticework/jali, we use ava for unit testing which requires inline source maps to integrate with it's use of the Babel transpiler. However some of our code will be in a browser, and, for production use, we don't want have inline source maps in that scenario. It appears that now we have no recourse but to specify the source map option on the command line since (1) --sourceMap and --inlineSourceMap are incompatable and (2) there is no way for a user to turn off a Boolean option from the command line.

Prior Art

• Babel supports the env property in babelrc and in project.json so that the settings for each environment can be supported.

Prior Discussion

3645 Support for multiple tsconfig.json per project

6109 Proposal: Support for multiple tsconfig.json per project

8500 Support multiple tsconfig files for different environments

A recent comment for #3645, made after the issue was closed, comes close to this idea.

[mhegazy]

--project/--p option allows for a full tsconfig.json file path. so you could have multiple tsconfig.json files, e.g. tsconfig.test.json and tsconfig.production.json and build each differently.

[yahiko00]

I am not a big fan of putting too much "intelligence" in tsconfig.json. I expect this file to be as close as possible to the compiler options.

[clavecoder]

so you could have multiple tsconfig.json files, e.g. tsconfig.test.json and tsconfig.production.json and build each differently.

@mhegazy, true, but if I want to modify only a handful of settings per environment it would be a management nightmare if I had to maintain, say, a list of all the source files, if that's what my team chooses to do, in all three tsconfig.json files just so I can set a couple of options differently per environment. Having env is a middle road between (1) Only One File and (2) Cascading Configuration Files, and seems to work well with Babel which is, in some sense, your closest competitor (at least with flow integration)

Remember, as currently implemented, overriding a Boolean flag is not an option in tsc.

[mhegazy]

but if I want to modify only a handful of settings per environment it would be a management nightmare if I had to maintain, say, a list of all the source files,

I would not say it is a nightmare. you also now have include and exclude with glob support, so no need to list all files.

We really do not want to complicate the tsconfig.json setup. one thing to keep in mind, this is used by editors, and adding profiles and build variables makes it harder for these environments to work correctly. also once such requirements seem to be in the realm of build tools more than that of a compiler.

having said that, we have talked about "inheriting" a tsconfig.json, so your smaller ones would point to a "main", and override it. we need to specify the behaviour of this though.

//cc: @chuckjaz

[pocesar]

@clavecoder I've created a grunt plugin that does exactly that. instead of creating thousands of tsconfig.json files, the task create them programmatically. you can cascade / override the options as well, and reuse existing tsconfig files.

[clavecoder]

having said that, we have talked about "inheriting" a tsconfig.json, so your smaller ones would point to a "main", and override it. we need to specify the behaviour of this though.

I had thought "inheriting" (or "cascading") was already discounted. Is there still an open issue for it? The three I mentioned in the Prior Discussion section of my suggestion are all closed.

"cascading"—tsconfig.json in subfolders—probably would not meet the user story in my suggestion; however, "inheriting" is something that would work. I had mentioned babelrc as prior art, I did not mention webpack.config.js because it's JavaScript, not JSON. Nevertheless, the prevailing pattern for webpack configuration is to explicitly inherit from a common configuration using the webpack-merge package (e.g.: angular2-webpack-starter).

So either the "env" or "inerit" would suffice. My preference is for "env" since it maintains the "Only One File per Project" spirit that has guided tsconfig.json design and since it is localized and therefore simpler to develop/reason about.

However, a word about task runners.

@pocesar

I've created a grunt plugin that does exactly that.

@mhegazy on #3645

this sounds like a build driver job something like grunt, gulp or msbuild

With the move toward module loaders such as systemjs and webpack, punting to a task runner is no longer an option, in my opinion, unless the typescript team wants to create sanctioned loaders that perform these tasks through options. I find that solution too obfuscating.

Since TypeScript targets large development projects, like enterprise applications, it should have some kind of native support for environment-based settings, which is well represented with prior art.

[mhegazy]

here is the proposal for inheriting configurations: #9876

[mhegazy]

Looks like #9876 covers this request.

[clavecoder]

I agree. Thanks, @mhegazy, and all the TypeScript team, for your service to the development community. Here's hoping #9876 has legs. It looks like it could fix several classes of problems.