Open slavafomin opened 6 years ago
You might be looking for rootDir
or baseUrl
? A concrete example of what you want to happen would be extremely useful.
Thank you Ryan for a response.
But, according to the docs, the rootDir
option affects only the output directory structure and the baseUrl
option is for non-relative modules (like node_modules
I guess?).
I will try to explain better. I have multiple projects with very similar directory structure and compilation requirements. I would like to define compilation options (including relative paths to source files from the root of the project directory) in a single place. Therefore I have a single tsconfig.json
file, which I want to use to compile multiple projects. However, the compiler is trying to resolve the source files, specified in the config, not from the project root directory, but from the directory, where this generic tsconfig.json
file is located.
Consider, I have the following generic tsconfig.json
file in ~/common/tsconfig.json
:
{
"compilerOptions": {
},
"include": [
"index.ts",
"src/**/*.ts"
],
"exclude": [
"node_modules",
"**/*.spec.ts"
]
}
And I have multiple projects like ~/project1
, ~/project2
, etc. I want to run the compiler like this:
tsc --project ~/common/tsconfig.json --projectRoot ~/project1
and I want it to start compilation using files, located in ~/project1/src/**/*.ts
and not in ~/common/src/**/*.ts
.
Also, I don't want to use extends
functionality of the tsconfig.json
, because I want projects to be agnostic from the location of the generic config.
I hope it makes sense.
I see. There's currently no support for this but we could think about ways to accomplish it. The scenario makes a lot of sense IMO
Thanks. I would love to see this implemented. Right now I have to manually use gulp-typescript
just in order to specify a list of files to compile. It would be nice to invoke tsc
directly.
This would be great!
+1 This feature would be awesome
I have the same use case. My team is currently building out a component library. The repo is a monorepo and each component is written in typescript. Currently I have to have a tsconfig.json
in each package that looks like this
{
"extends": "../../tsconfig.json",
"include": ["src/**/*", "../../typings/**/*"]
}
This is a lot of duplication. I need to add another tsconfig for build related things. To do this in my current setup I would have to double the amount of tiny tsconfigs in the project.
I've been playing around with moving the tsconfig to our scripts
package but can't get it to work because file resolution is relative to the tsconfig. If there was some way to set the --projectRoot
from the cli I could get rid of all of these tiny files. It is important that i can set it from the CLI too. A tsconfig option would not suit my use case.
This is a big issue when using "extends": "path/to/tsconfig.json"
. It means the extending config can't use includes
, excludes
, outDir
, rootDir
, or any option that includes a path as the path to these files are relative to the tsconfig that is extending, instead of being relative to the tsconfig that is extended, which makes a lot more sense.
Very surprising to not be able to compile just the src directory for exemple. I have some utils directories in my projects which I don't need to be compiled. Additionally I would like to have the src
and dist
dir at the same level. Looks like I need babel to do that or did I misunderstood something ?
@l1br3 you should be able to have those at the same level. Here is an example https://github.com/hipstersmoothie/eslint-formatter-github
The @microsoft/rush-stack-compiler-3.4
package works around this by using paths like this:
rush-stack-compiler-3.4/includes/tsconfig-base.json
{
"$schema": "http://json.schemastore.org/tsconfig",
"compilerOptions": {
"outDir": "../../../../lib",
"rootDirs": ["../../../../src/"],
This allows it to be imported like in this example:
{
"extends": "./node_modules/@microsoft/rush-stack-compiler-3.4/includes/tsconfig-node.json",
"compilerOptions": {
"types": [
"jest",
"node"
]
}
}
However this ../../../..
workaround relies on two assumptions:
@microsoft/rush-stack-compiler-3.4
package is a direct dependency of the project being built; AND./node_modules/@microsoft/rush-stack-compiler-3.4
. This is true for NPM, PNPM, and Yarn classic, but from what I read it maybe would /not/ be true for Yarn Plug'n'Play.Really the TypeScript compiler should define tokens that make it more explicit how relative paths are resolved. For example, jest.config.json supports a <rootDir>
token, and api-extractor.json supports a <projectFolder>
token. That way a shared base configuration can specify paths like "mainEntryPointFilePath": "<projectFolder>/lib/index.d.ts"
without any ambiguity what it is relative to.
Also "extends"
should support module resolution, so we can write "extends": "@microsoft/rush-stack-compiler-3.4/includes/tsconfig-node.json"
instead of assuming a specific node_modules
folder placement.
This seems pretty straightforward to implement for TypeScript's tsconfig.json
.
@slavafomin One thing you can do is publish your tsconfig in an NPM package, then in each project just npm install
in each project so that, for example, it will always be located in each projects' node_modules/your-config-package/tsconfig.json
and then you can hard code ../../src/**/*
inside of that tsconfig.json file and it will resolve to the files that you expect in each project.
@RyanCavanaugh One problem is that rootDir
or baseUrl
have no effect on includes
and exclude
paths. includes
and exclude
seem to always be relative to the tsconfig.json
file, regardless of where it is.
If there was a new top-level option (f.e. projectDir
or something), then this could point to some arbitrary location, and all other options (rootDir
, rootDirs
, baseUrl
, outDir
, include
, and exclude
would all be relative to this projectDir
setting).
This would then make it feasible that in each project's tsconfig, we could do something simple like
{
"extends": "./node_modules/my-configs/tsconfig.json",
"projectDir": "./"
}
and at that point any paths in node_modules/my-configs/tsconfig.json
will always work due to the projectDir
being specified. The tsconfig
file could be located anywhere, and it would just work.
As @octogonz mentioned, being able to specify module identifiers in extends
would be convenient too.
Any updates on this?
It looks like TypeScript compiler resolves files relative to the location of the
tsconfig.json
file (however, I couldn't find anything about paths resolution in the official documentation).Is there a way to specify an alternative base/working directory, which will be used for relative paths resolution?
I want to use a generic
tsconfig.json
file to compile multiple projects in various directories (one at a time).P/S: I've created a question on StackOverflow first, but haven't received any attention there, so I've decided to ask here directly.