Allow to specify the tsconfig.json filename explicitly

[zpdDG4gta8XKpMCd]

currently VSCode uses the file with the exact name tsconfig.json in the folder as the project file for a typescript project,

i have a few other project files named differently for corresponding sub-projects inside the same folder, I wish there was a way to tell VSCode to use one of them rather then the default tsconfig.json

[dbaeumer]

@waderyan this first needs support in the tsserver IMO. We can't tell tsserver the name or location of a tsconfig.json.

[waderyan]

@Aleksey-Bykov thank you for opening this issue. I'm not sure I completely understand.

Can you provide a simple example of what you are describing?

Is it something like this?

MainProject/
--- tsconfig.json
--- SubProject-X/
------src/
------tsconfig.json
--- SubProject-Y/
------src/
------tsconfig.json

And your feature request is to have SubProject-Y be able to use MainProject/tsconfig.json?

[zpdDG4gta8XKpMCd]

no, i have it differently, in the folder structure that you showed there is no problem to compile a sub-project if the VSCode is run from under a sub-folder

my file structure looks like this:

- shared-libs
- shared-assets
- client-side
- server-side
- tsconfig.server.json
- tsconfig.client.json

I want to be able to focus either on tsconfig.client.json or tsconfig.server.json

[waderyan]

Interesting. Ok moving to TS repo.

[waderyan]

This issue was moved to microsoft/TypeScript#11224

[zpdDG4gta8XKpMCd]

please reopen

it looks like there is a way per microsoft/TypeScript#11224 (comment)

    // https://github.com/Microsoft/TypeScript/blob/master/src/server/protocol.ts#L330



    /**
      * Response message body for "projectInfo" request
      */
    export interface ProjectInfo {
        /**
          * For configured project, this is the normalized path of the 'tsconfig.json' file
          * For inferred project, this is undefined
          */
        configFileName: string; // <--- HERE!
        /**
          * The list of normalized file name in the project, including 'lib.d.ts'
          */
        fileNames?: string[];
        /**
          * Indicates if the project has a active language service instance
          */
        languageServiceDisabled?: boolean;
    }

[waderyan]

@Aleksey-Bykov thank you. Let's take another look here.

@dbaeumer looks like this is available in protocol.ts (see comment above).

[dbaeumer]

@waderyan no. This defined interface is a response message that is sent from the server to the client to let the client know which files belong to a tsconfig.json file.

The tsserver currently doesn't expose any API to configure the name of the tsconfig.json. With 2.0.6 there is APi to manage the project totally on the client side but that would require us to do all the tsconfig.json file parseing, lookup, ... So I opt to not do that on the client side since it would put us in a constant catchup game.

[wclr]

Can it be achieved? I've got problem with VSCode because it tries to use tsconfig files from subdirectories and that causes tsserver to restart.

[Qythyx]

I have a slightly different scenario that causes me to want this feature. My folder structure is:

MainProject/
--config/
----bs-config.json
----tsconfig.json
----tslint.json
--src/
--build/

I'm trying to put all my config files in that config folder instead of polluting the root. This works except that VSCode won't detect my tsconfig.json in there.

[davidmatas]

I would love to see this implemented.
I have problems for tests files that I think I would resolve if I can specify a tsconfig file to vscode.

The problem is my configuration for tsconfig excludes test files:

...
"exclude": [
    "node_modules",
    "**/*.test.ts",
    "**/*.test.tsx",
    "**/*.test.js"
  ]

When I open one of these files in vscode, it can't resolve absolute paths I specify in compilerOptions:

"compilerOptions": {
...
  "paths": {
      "*": ["app/*", "*"],
  }
}

So I get a lot of ugly warnings

At the moment the workaround I'm using is leave tsconfig file for vscode dev development, and use differents tsconfig files for dev and production builds

[adrienDog]

I have exactly the same issue as above

[valera33]

+1

would be nice to be able to set the path of tsconfig.json in settings.

[michael8090]

any update here?

With git submodules, the problem is much more obvious.

[renewooller]

I would love this feature so as to fix the tsconfig.json in my project not being used by VSCode. The answers in https://stackoverflow.com/questions/38268776/why-does-typescript-ignore-my-tsconfig-json-inside-visual-studio-code. do not work for me, so I'd love to be able to explicitly set it. I'm also using submodules.

[f1am3d]

What if I have several tsconfig's for several sub-folders in my project?

[dosentmatter]

I am using Typescript for React development with multiple tsconfig.json's. I have a project structure like this:

.
├── scripts # build/test running scripts
│   └── script.ts
├── src
│   └── index.ts
├── tsconfig.json
└── tsconfig.test.json

tsconfig.json uses esnext modules because the compiled React code goes to webpack, which understands es6 modules:

# tsconfig.json
{
  "compilerOptions": {
    "module": "esnext"
  }
}

tsconfig.test.json uses commonjs modules because tests are run in node, which doesn't understand es6 modules:

# tsconfig.test.json
{
  "compilerOptions": {
    "module": "commonjs"
  }
}

Scripts are run in node but they use tsconfig.test.json.

My solution was just to add a scripts/tsconfig.json that extends tsconfig.test.json

.
├── scripts
│   ├── script.ts
│   └── tsconfig.json # Add this
├── src
│   └── index.ts
├── tsconfig.json
└── tsconfig.test.json

# scripts/tsconfig.json
{
  "extends": "../tsconfig.test.json"
}

I commit scripts/tsconfig.json to source control even though it's only for text editors.

[danielmhair]

I'm using Angular 6 and I noticed this issue, as well. I just had to make sure that the name of my tsconfig.json file closest to the file that is having an issue, is named tsconfig.json. I had another name for my tsconfig.json, which is why it messed up.

[evg656e]

Need this feature so badly.

[Jack-Barry]

This would be an awesome feature to have, and I've found some behavior that might be helpful. My project's structure is basically the following:

.
├── config/
│   ├── tsconfig.json
│   └── webpack.config.js
├── dist/
│   ├── index.html
│   └── bundle.js
├── node_modules/
├── src/
│   ├── index.tsx
│   ├── index.html
│   └── components/
│       └── App/
│           ├── App.tsx
│           └── index.ts
├──.gitignore
├──package.json.lock
└──package.json

The idea is that all configuration can be kept in one place and not have to litter the root directory. Now, with the proper setting in Webpack config, I am able to use the paths from tsconfig.json to set aliases. Everything compiles nicely and my bundle.js works.

If I have my webpack.config.js file open in VSCode, no errors are thrown and VSCode knows how to handle my project's aliased imports. Here's what I see when I have webpack.config.js open:

The strange part is that if I close the webpack.config.js file, then reopen a file with an aliased import (in this case src/index.tsx), VSCode no longer knows where to get the tsconfig.json settings from and the error re-emerges. Here's what I see if webpack.config.js is closed, and I haven't made any changes to the files in my project:

I have a repo here which can be used to demonstrate. Let me be clear that I'm not trying to suggest relying on Webpack for this functionality, I'm just wondering if the mechanism that's causing it to let VSCode know where the tsconfig.json is at might be able to be used somehow. If there's anything else I can provide to help get this feature off the ground please let me know, thanks!

[anoadragon453]

Would also really like to see this feature included. I currently have a similar setup to @Qythyx.

[kyusupov33]

same problem here...

[msanguineti]

Is there any progress for this issue?

[a7madgamal]

I'm amazed this is not as simple as for setting a different tslint config file!

[brandon-sigao]

I'm in the same boat as everyone else. Using VS Code for Nativescript means you can't use absolute paths to import code. Any "@MyApp/..." type paths are not recognized because VS Code assumes that my tsconfig file (which is set to exclude all .tns.ts files) is the correct one to use to resolve imports. These imports actually DO work after building the app because Nativescript replaces tsconfig with tsconfig.tns.ts during the build, however during development most of our imports show up red which is highly confusing and causing lots of issues.

[lonix1]

I have the same problem due to a different use case - my config files start with . according to the common convention on posix. So I have .tsconfig.json, .tsconfig.test.json, .tsconfig.prod.json etc.

The app itself works. All my tools can be configured to recognise the different filenames. But vscode doesn't and makes every file red.

Please allow us to explicitly specify the ts project file as a config option.

---

SIDE NOTE: my workaround is a dummy tsconfig.json in each subproject in my project:

{
  "extends": "./.tsconfig.json",
}

All my tools are configured to look for the correct config files, so they ignore this one.

[jeremyhon]

Hi, this is still an issue for us. Our use case is to migrate a codebase to use strict null checks only in the IDE but not to block compilation (i.e. enabling new TS features: tsconfig.strict-null-checks-wip.json).

The referenced issue in microsoft/TypeScript#11224 was closed and went horribly off topic. Is it possible to reopen that issue (or open a new one?) since as I understand it this issue needs to be fixed in that repo.

[mike-d-davydov]

+1. We badly need this to be implemented in order to have an ability to place our Jest and WDIO tests next to the features they are testing. tsconfig for Jest and WDIO are incompatible with the ones for our react code. As a result, autocomplete doesn't work for WDIO classes which makes an VSCode as an IDE pretty useless.

[cruhl]

This is causing serious issues when using TS and Lerna.

[wolcotts]

My project structure is also similar where multiple non-local tsconfig.json files are used to transpile the same library source for testing against different environments. Specifying one of the non-local configs would drop the need for a workaround to enable source navigation and squiggle removal.

[jrmyio]

Running into similar issues where I have multiple directories having tsconfig files, the folders contain some shared code and they may reference each other (using tsconfig's paths). As soon as I (close-)open a file from one of the folders it has to "Initializing JS/TS Language features". I would really love to point all of them to one of the tsconfig files that is sitting in one of the sub directories (a directory that contains code that is NOT shared but actually implements the other subdirectories).

A workspace setting that would allow to specify a tsconfig for the workspace would fix this issue for me.

[tanekim88]

This is a must have feature

[amaschas]

This issue is almost three years old at this point and it should have been a day-one feature. Can we get some movement on this?

[kenmlee]

My solution is add typescript compiler options to environment variables.
It work for me debugging with ts-node.

in launch.json:
{ "type": "node", "request": "launch", "name": "Current Typescript File", "env": { "TS_NODE_COMPILER_OPTIONS": "{\"module\":\"commonjs\"}", }, "args": [ "${relativeFile}" ], "runtimeArgs": [ "--nolazy", "-r", "ts-node/register", ], "sourceMaps": true, "cwd": "${workspaceFolder}", "protocol": "inspector" }
Try to adjust it to your requirements.

[nelisbijl]

My goodness, no progress after THREE years?
Ionix's solution does not work as unfortunately there are more tools like VSCode that do not allow to specify a dedicated tsconfig. And that's exactly why it is so important that VSCode does.
Furthermore I can not understand why this option hasn't been made years ago. What's holding them back?

[mjbvz]

I've locked this issue because many of recent comments are not constructive and are just polluting the conversation. Suffice it to say: if doing this were as easy and had zero repercussions, we would have already done it