Repository navigation
Support for multiple tsconfig.json per project #3645
Description
Hi! Is it possible to use multiple tsconfig.json per project, that is some kind of project-wide tsconfig.json located in root directory and additional tsconfig.json files located in sub-directories which may override/tune some options for that dirs? Like .gitignore does.
It would be very usefull when, for instance, developing external module under node-environment. Such modules usually splited into multiple files (internal modules), but would be compiled into one big file during compilation stage.
Activity
DanielRosenwasser commentedon Jun 26, 2015
Hey lazutkin. Currently that's not supported, though I just want to link this issue to #2869 because it is somewhat related.
mhegazy commentedon Jun 26, 2015
The compiler picks the closest tsconfig.json to the folder you are building if you are running
tscwith no arguments in a folder. so if you have an inner directory with a tsconfig.json it will be picked up before the one in the outer directory.I do not think we will support integration/overriding configuration from multiple tsconfig.json.
Eisenspalter commentedon Jul 1, 2015
Multiple tsconfig files are indispensable for large enterprise apps.
Suggestion: Everytime tsc find a new tsconfig file in a subdirectory, tsc stopps here and create a new tsc process with its own tsconfig file.
mhegazy commentedon Jul 1, 2015
Eisenspalter (@Eisenspalter) this sounds like a build driver job something like grunt, gulp or msbuild.
lazdmx commentedon Jul 1, 2015
Mohamed Hegazy (@mhegazy) I agree with Eisenspalter (@Eisenspalter) because we both talk not about building process but about development process including sources writing, testing and other activities we need to complete before build. On all this intermediate steps we need to have support from
typescriptincluding intellisense, typechecking etc. Moreover as I said before, for different parts of project we would like to apply different source organizing techniques (external-internal modules, single output file, etc) and here we need some options to be overriden by separate tsconfig.Eisenspalter commentedon Jul 1, 2015
Mohamed Hegazy (@mhegazy) Why closed? Please reopen.
mhegazy commentedon Jul 1, 2015
you can have multiple tsconfig today, each pointing to overlapping set of files. so one at src\tsconfig.json, one in tests\tsconfig.json, etc.. the compiler/tools will locate the file by walking up the directory tree to find the closest one. so you can have a third file at the root to catch all.
This all works today, in the compiler and the different IDEs. the original issue was about allowing a file to inherit from another. i do not think there is enough value there warrants the complexity.
For the second issue:
As i mentioned earlier, a tsconfig.json represents a single invocation to tsc.js/tsc.exe if you want to do multiple invocations you should use a build driver.
lazutkin and Eisenspalter (@Eisenspalter) does this answer the questions
Ziink commentedon Dec 12, 2015
Mohamed Hegazy (@mhegazy)
Couldn't get multiple tsconfig.json to work. At least with TypeScript 1.7.3, only one tsconfig.json is read and that is expected to be in the root directory (or parent) of the project.
mhegazy commentedon Jan 5, 2016
Ziink my comment above was not about multiple tsconfigs in the same project. it was about multiple projects/directories, each with a different tsconfig. this how the ts project is layed out, see https://github.com/Microsoft/TypeScript/tree/master/src, each folder under src, has a different tsconfig.json
bartosz-k commentedon Feb 15, 2016
I have project that is written in TypeScript and I want to target both:
/browser) with ES5/AMD andserver) with CommonJS and generators (and async/await in TS).There are some shared files let's say in (
/common) folder and there are imports fromcommontobrowserandserver.How can I achieve such config preserving IDE support, all the errors etc? I'm not sure if the discussion answered my doubts.
mhegazy commentedon Feb 23, 2016
Bartq With TS 1.8, I would create two tsconfig files, one for browser, and one for server, and add ///references in your files in both sub-projects to the common ones. give it a try and let us know if this addresses the scenario or there are still missing pieces.
bartosz-k commentedon Feb 24, 2016
actually I'm using those two
tsconfig.jsonfiles, WebStorm discovers them and runs the compilation automatically. To be precise, backend code imports some classess from frontend code (instead usingcommonconcept), but it all works fine.mignonat commentedon Apr 9, 2016
I finally get the solution.
my application structure :
-- app/
-- app/client/ (my client side source code)
-- app/server/ (my server side source code)
-- app/build/ (where I generate the js)
-- app/node-modules/
-- app/package.json
-- app/tsconfig.server.json
-- app/tsconfig.client.json
Content of tsconfig.server.json :
{ "compilerOptions": { ..., "outDir": "build/server" },
"exclude": [ "node_modules", "client"] }
Content of tsconfig.client.json :
{ "compilerOptions": { ..., "outDir": "build/client"},
"exclude": [ "node_modules", "server"] }
Then when I want to compile server source code I use this command from app root directory :
#tsc --p tsconfig.server.json
And to compile client source code, also from root app directory :
#tsc --p tsconfig.client.json
In order to run both client & server compilation, I added a command in package.json :
"scripts": { ..., "tsc": "tsc --p tsconfig.server.json && tsc --p tsconfig.client.json", ... }
Then to compile both server and client I just run this from my root app directory :
#npm run tsc
Hope this comment could help you :-)
10 remaining items
zhukovka commentedon Mar 13, 2017
I can't get it working
It insists on "Warning:Cannot find parent tsconfig.json" although I have tsconfig.json in the same folder, don't know what to do with this
RyanCavanaugh commentedon Mar 13, 2017
Lena Zhukova (@zhukovka) please log a new issue with a standalone repro we can run locally
zhukovka commentedon Mar 13, 2017
Ryan Cavanaugh (@RyanCavanaugh) Oh. thanks, I've figured it out
the problem reproduces only if I have one file open from a test folder (that didn't include tsconfig.json) and the second file opened in an 'src' folder (that included tsconfig.json)
and the file from the test folder imports the one from the src folder. In this case, the file from the src folder doesn't see his 'parent tsconfig.json'
BurtHarris commentedon May 31, 2017
Ryan Cavanaugh (@RyanCavanaugh), support for compiling with several different tsconfig.json's seems to continue be something developers would like to have. For my cases, its generally about changing where the generated output files go. It seems like if the code generations could be controlled by something like the existing
pathsmapping allowing me to layout my generated code differently from the sources, perhaps the need for multiple projects would be lessened.pelotom commentedon Aug 29, 2017
My use case is that I have a large legacy codebase which can't withstand the stricter type checking rules, and I want to use it in a new codebase which does have strict checks enabled, and I can't compile the legacy code to a library because it has a million cases where it doesn't import all the types required to name the types for its exports (#9944). So I want to just add the legacy codebase to the new codebase, but compiled according to laxer rules. This can't be 2 different compilation steps; just when the compiler is working on source files under a certain directory it should be using the laxer rules.
voy commentedon Sep 7, 2017
For me the use case is having part of the repo that is run using node and needs to compile down to commonjs modules, while the other part needs to be compiled to ES6 modules in order to enable treeshaking in ES6. The experience isn't great, there is a lot of hacking around with
TS_NODE_PROJECTenvironment variables, in my case. It definitely seems like something that could confuse the hell out of the next person maintaining it when I eventually change projects.Robinfr commentedon Sep 15, 2017
I would still love to see this solved. It would be a huge win for larger projects that require different
tsconfig.jsonfiles per module within a project.kitsonk commentedon Sep 15, 2017
Robin Franken (@Robinfr) what does the
extendsfeature not solve for you?Robinfr commentedon Sep 15, 2017
voy commentedon Sep 19, 2017
Kitson Kelly (@kitsonk) extending works well, although if I am not doing something wrong, I have to repeat certain settings (excluding my build and node_modules folders) in both configs. for me the biggest pain point is making sure all my tooling knows which configuration file is the correct one too use (typically by means of something like a
TS_NODE_PROJECTenvironment variable. The other is when opening a project with two tsconfigs in VS.code. There is no way (that I know of) to tell VS which project file to use and that means for some files errors will not get correctly underlined, because of different settings for those files in the corresponding tsconfig (say, something like tsconfig.build.json).Robinfr commentedon Sep 20, 2017
Vojtech Jasny (@voy) may I ask why you have a different tsconfig for building? As far as I've understood, VSCode uses the nearest tsconfig file (
tsconfig.json) to the file you're editing. The only issue I've had so far is that you need to have a tsconfig file at the root before VSCode seems to start using the configs at all...voy commentedon Sep 20, 2017
Robin Franken (@Robinfr) sure. in the same repository I have files that get processed using webpack & babel and use ES6 modules to enable tree-shaking. other files are part of the build process and get executed using node, which is why imports need to get transpiled to requires. not sure how I could work around that.
Robinfr commentedon Sep 20, 2017
Vojtech Jasny (@voy) wouldn't you just have those files in a separate folder however? E.g. 1 folder for all the Babel & webpack files, and 1 for the node files. Then you can just have a tsconfig.json for each of those folders. Wouldn't that work for you?
voy commentedon Sep 21, 2017
Robin Franken (@Robinfr) that would be ideal, but I think it isn't always possible in the real world. for example, we want all our configuration files to be typescript as well, compiled and linted according to the very same rules as all of TypeScript codebase and some files have to be in the root of the project. you could symlink, but that sometimes brings out other problems. that's why I feel something more flexible would be a benefit.