-
Notifications
You must be signed in to change notification settings - Fork 12.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for multiple tsconfig.json per project #3645
Comments
The compiler picks the closest tsconfig.json to the folder you are building if you are running I do not think we will support integration/overriding configuration from multiple tsconfig.json. |
Multiple tsconfig files are indispensable for large enterprise apps. |
@Eisenspalter this sounds like a build driver job something like grunt, gulp or msbuild. |
@mhegazy I agree with @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 |
@mhegazy Why closed? Please reopen. |
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 does this answer the questions |
@mhegazy |
@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 |
I have project that is written in TypeScript and I want to target both:
There are some shared files let's say in ( |
@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. |
actually I'm using those two |
I finally get the solution. my application structure : Content of tsconfig.server.json : Content of tsconfig.client.json : Then when I want to compile server source code I use this command from app root directory : And to compile client source code, also from root app directory : 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 : Hope this comment could help you :-) |
I don't understand what the problem is here. Why can't we support configs with different file names? It's a pain having to create subFolders JUST to have a different tsconfig file in. |
You can. --p argument ca be a file name. |
The different file names won't work with the Visual Studio typescript compiler extension (not talking about CLI) out of the box though. Only way to do that is to put each tsconfig.json in a dummy directory, and have it link back to the typescripts you want with the for example --src/target/search/tsconfig.json target/search/tsconfig.json would look something like:
And the others would be similar. This would produce 3 javascript files, each with its own configuration of files, bundled into one. Of course, your could use a different solution of bundling/minimizing/packaging than the Typescript compiler itself. It's just that the Typescript compiler does a really good job with optimization - that's one of the biggest draws to using Typescript. So, it would be nice if a single tsconfig.json could support multiple configurations by just changing it to be an array of tsconfigs:
This is what it sounds like is being requested in the later comments of this issue, although I agree, the original issue was more about inheritance and overriding configs. |
@mhegazy @Bartq I cannot make it work with
Yet, when I run |
@tomitrescak I'm using WebStorm and it's intelligent enough to find closest tsconfig.json and use it when you edit a file. Probably there isn't any cmd tool that supports watching multiple tsconfig.json's. You can roll it out using for example FB watchman. |
Yeah, I'd love to have something like this in VS Code. I'm running the compilation in the terminal. Works as well. VS Code correctly identifies errors anyways. |
Multiple configs would be great. I am working on a React-Native project and basically I have two builds that I want to do:
|
Configuration inheritance has been added in TS 2.1, and should be available in |
I have a following directory structure: ├── examples
│ ├── files...
│ └── tsconfig.json
├── src
│ └──files...
└── tsconfig.json Root {
"compilerOptions": {
"target": "es2015",
"module": "commonjs",
"moduleResolution": "node",
"outDir": "dist",
"sourceMap": true,
"emitDecoratorMetadata": true,
"experimentalDecorators": true,
"removeComments": false,
"noImplicitAny": false,
"declaration": true,
"allowJs": false
},
"include": [
"./src"
],
"compileOnSave": false,
"buildOnSave": false,
"atom": { "rewriteTsconfig": false }
}
"include": [
"./hello-world"
], When I do: cd examples
tsc It compiles: ├── examples
│ ├── dist
│ │ ├── examples
│ │ └── src
│ ├── files...
│ └── tsconfig.json
├── src
│ └── files...
└── tsconfig.json ( Not help this (in "exclude": [
"../src"
], What am I doing wrong? |
I found problem. If in my import { SomeClass } from '../../src'; It's produce described above problem. Following import works as expected: import { SomeClass } from '../../'; But why typescript's directive |
I can't get it working |
@zhukovka please log a new issue with a standalone repro we can run locally |
@RyanCavanaugh Oh. thanks, I've figured it out |
@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 |
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. |
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 |
I would still love to see this solved. It would be a huge win for larger projects that require different |
@Robinfr what does the |
It did. I found out about that after this post. One thing to note however is that it didn't work without setting the `include` to the files which k usually don't have to since it goes through webpack.
Op 15 sep. 2017 9:24 a.m. schreef Kitson Kelly <notifications@github.com>:
@Robinfr<https://github.com/robinfr> what does the extends feature<https://www.typescriptlang.org/docs/handbook/tsconfig-json.html#configuration-inheritance-with-extends> not solve for you?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#3645 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AD90FLZKcHMJeFU0osJroT_yawlC1oTIks5siiZFgaJpZM4FMc8w>.
|
@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 |
@voy may I ask why you have a different tsconfig for building? As far as I've understood, VSCode uses the nearest tsconfig file ( |
@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. |
@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? |
@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. |
Hi! Is it possible to use multiple
tsconfig.json
per project, that is some kind of project-widetsconfig.json
located in root directory and additionaltsconfig.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.The text was updated successfully, but these errors were encountered: