tsconfig.json: is multiple build configurations possible?

[niemyjski]

What's the best way to accomplish multiple build profiles with tsconfig? I want to have builds that specifically target different platforms like node/browser etc..

{
   es5: {
      compilerOptions: {
        target: 'es5',
      },
      files: [
        'polyfill.ts',
        'index.ts'
      ]
   }
   es6: {
      compilerOptions: {
        target: 'es6',
      },
      files: [
        'index.ts'
      ]
   }
   nodees5: {
      compilerOptions: {
        target: 'es5',
      },
      files: [
        'polyfill.ts',
        'index.ts',
        'nodexyz.ts'
      ]
   }
   nodees6: {
      compilerOptions: {
        target: 'es6',
      },
      files: [
        'index.ts',
        'nodexyz.ts'
      ]
   }
}

[mhegazy]

That is not supported.. but nothing stops you from having multiple tsconfig files instead.. so assuming you have this directory structure:

|- es5
|   | - tsconfig.json
|- es6
|   |- tsconfig.json
index.ts

you can build twice:

tsc -p es5

and

tsc -p es6

[niemyjski]

Thanks for the heads up. What about specifying the full name of the tsconfig.json? so we don't have to have multiple sub folders? Also, I just created an issue about possibly using a tsconfig.json file for references for other typescript files.. What's the best way to do multifile references?

[mhegazy]

There is an assumption that a tsconfig turns a folder to a project. calling tsc in a directory will walk up the directory tree to find the first tsconfig. tsconfig.json was initially added to support a directory-based project system, which is a common convention; hence the assumptions about directory affinity.

[mhegazy]

closing this issue for now, please reopen if there further details needed.

[mindplay-dk]

nothing stops you from having multiple tsconfig files instead

well, it messes up the module names if you're using outFile

There is an assumption that a tsconfig turns a folder to a project. calling tsc in a directory will walk up the directory tree to find the first tsconfig. tsconfig.json was initially added to support a directory-based project system, which is a common convention; hence the assumptions about directory affinity.

Makes sense, but it seems there is still a practical need for multiple configurations - for example, I have my tsconfig.json set up for development use, e.g. tsc -w, but now I need an alternative configuration for release builds, e.g. with comments removed, and the test folder excluded from compilation.

My first thought was to put the additional command-line options in a file and use e.g. tsc @release to apply the extra settings - but unfortunately, the exclude option from tsconfig.json is not available via the command-line.

So, currently, it seems there's no way to do that?

Would it be problematic to allow extra configuration files in addition to tsconfig.json, e.g. tsconfig.release.json, and add a command-line switch to select the specific build configuration to use?

The tsconfig.json file would still be there, and would still be the file that turns a folder into a project, and this would have the configuration setting you want to use for development, e.g. in VS-code - so you would want to include test-modules and have options like source-maps turned on in the default configuration file.

So a command like tsc --build release would look upwards for tsconfig.release.json instead of the default tsconfig.json.

It seems the only alternative right now is to switch to a grunt setup or something, and, ugh... I really don't want a bunch of third-party dependencies, and we're so close to tsc being able to simply do everything we need to do without additional tools...

Thoughts?

[mhegazy]

Would it be problematic to allow extra configuration files in addition to tsconfig.json, e.g. tsconfig.release.json, and add a command-line switch to select the specific build configuration to use?

this is how it works today,TS 1.8+, --p takes a filename or a folder, so tsc --p tsconfig.release.json should work.
see https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in-TypeScript#the---project--p-flag-can-now-take-any-file-path for more infroation

[mindplay-dk]

Oh, awesome :-)

The --help option doesn't explain this - it says the argument is a directory.

-p DIRECTORY, --project DIRECTORY   Compile the project in the given directory

This probably needs to be updated?

[mhegazy]

correct. a PR would be definitely appreciated.

[rposener]

Just a quick thought - this could be really helpful in the following scenario:

Using AMD or some type of module resolution, but need to compile a few files without module logic (e.g. webworkers). Without it, we are left to just using Javascript instead of Typescript!