Set TypeScript compiler's base/working directory

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.

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

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:

ts-command-line/tsconfig.json

{
  "extends": "./node_modules/@microsoft/rush-stack-compiler-3.4/includes/tsconfig-node.json",

  "compilerOptions": {
    "types": [
      "jest",
      "node"
    ]
  }
}

However this ../../../.. workaround relies on two assumptions:

The @microsoft/rush-stack-compiler-3.4 package is a direct dependency of the project being built; AND
The package manager installs it in the specific subfolder ./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.

fix: tsconfig should list its own path

feat: typescript infrastructure and few components conversion (#1797)

Slava (@slavafomin)

Slava (@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.

Ryan Cavanaugh (@RyanCavanaugh)

Ryan Cavanaugh (@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 Pete Gonzalez (@octogonz) mentioned, being able to specify module identifiers in extends would be convenient too.

feat: add initial tsconfig bases

Any updates on this?

Navigation Menu

Repository navigation

Set TypeScript compiler's base/working directory #25430

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Set TypeScript compiler's base/working directory #25430

Description

Activity

RyanCavanaugh commented on Jul 5, 2018

slavafomin commented on Jul 5, 2018

RyanCavanaugh commented on Jul 5, 2018

slavafomin commented on Jul 7, 2018

itonics-tbeauvais commented on Dec 13, 2018

siddthesciencekid commented on Jan 11, 2019

hipstersmoothie commented on Mar 20, 2019

TidyIQ commented on Jul 9, 2019

Fr33maan commented on Aug 16, 2019

hipstersmoothie commented on Aug 18, 2019

octogonz commented on Oct 9, 2019

trusktr commented on Feb 8, 2020

trusktr commented on Feb 8, 2020

ramesaliyev commented on Jul 23, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions