Add way force TS Server to use a specific set of tsconfig/jsconfigs #33094
Comments
mjbvz
changed the title
mjbvz
changed the title
|
Vs uses external projects and it can contain tsconfig files .. may be we could use that approach instead.. |
mjbvz
added
the
VS Code Priority
RyanCavanaugh
added
Committed
|
Users/matb/project/test/tsconfig.dev.json. This could either be configured using a server command line flag or using the configure |
|
Removing the "committed" label, not because I don't think this is going to happen, but because "Committed" implies it's on the next roadmap. Having spoken offline, we will likely revisit this in the future in the next 6-months. |
DanielRosenwasser
added
the
VS Code Tracked
RyanCavanaugh
removed
the
VS Code Priority
|
Tentatively slotting for 3.9 |
RyanCavanaugh
added
the
Rescheduled
|
@RyanCavanaugh Would you take a pull request for this? If so, has it been decided whether a command line flag or configure request would be preferred? |
|
Any update on this? Anything any of us can do to help move this along? |
It is well-documented (see 1-6 below) that VSCode doesn't support setups like ours, where multiple tsconfig files coexist in a single directory. Strangely, though, it is only recently that this has become a problem, with VSCode at random intervals forgetting that it's ever heard of `expect` or `describe` (because it's not seeing `tsconfig.test.json`, but taking a while to realize it). There is an open issue[7] tracking the addition of support for this, but it's been open for a long time, with little movement. In the meantime, this solves the problem by adding placeholder `test/tsconfig.json` files to each package, each pointing to its corresponding `tsconfig.test.ts` file. I went with this approach over simply moving and renaming the existing test tsconfigs because this allows us to stay consistent in having all flavors of tsconfig for a package live at the package root level, and provides an easy way to reverse this workaround, should VSCode ever fix the underlying problem. [1] angular/angular-cli#5175 [2] microsoft/TypeScript#49210 [3] microsoft/vscode#107750 [4] microsoft/vscode#12463 [5] sillsdev/bible-karaoke#175 [6] microsoft/TypeScript#8435 [7] microsoft/TypeScript#33094
It is well-documented (see 1-6 below) that VSCode doesn't support setups like ours, where multiple tsconfig files coexist in a single directory. Strangely, though, it is only recently that this has become a problem, with VSCode at random intervals forgetting that it's ever heard of `expect` or `describe` (because it's not seeing `tsconfig.test.json`, but taking a while to realize it). There is an open issue[7] tracking the addition of support for this, but it's been open for a long time, with little movement. In the meantime, this solves the problem by adding placeholder `test/tsconfig.json` files to each package, each pointing to its corresponding `tsconfig.test.ts` file. I went with this approach over simply moving and renaming the existing test tsconfigs because this allows us to stay consistent in having all flavors of tsconfig for a package live at the package root level, and provides an easy way to reverse this workaround, should VSCode ever fix the underlying problem. [1] angular/angular-cli#5175 [2] microsoft/TypeScript#49210 [3] microsoft/vscode#107750 [4] microsoft/vscode#12463 [5] sillsdev/bible-karaoke#175 [6] microsoft/TypeScript#8435 [7] microsoft/TypeScript#33094
|
@RyanCavanaugh any update on this? Is there anything we can do to make this done? |
|
Bump |
|
This issue is almost 5 years old, with an update from 2020 saying "we will try to plan this in the next 6 months"... Is there any plan to move forward on this? |
|
just a friendly little bump |
From microsoft/vscode#12463
Search Terms
Problem
Some common project templates (such as angular) generate config file with names such as
tsconfig.dev.json. The TS Server used by VS Code will not load this project because the file is not namedtsconfig.json. We only load project files exactly namedtsconfig.jsonFeature Request
Allow users to configure a specific set one or more project config files that the TS Server should load, such as
/Users/matb/project/test/tsconfig.dev.json. This could either be configured using a server command line flag or using theconfigurerequest in TSHow do we handle additional projects?
If specific project files have been configured, one proposal is that we only load those projects (and never fall back to loading additional projects). Using this approach, when a user opens a new file:
As an alternative to this to better support multi-root workspaces in VS Code, we could instead only fall back to loading an additional project if that project is not under the roots of any of the configured projects. For example, if I configured
/Users/matb/project/test/tsconfig.dev.jsonas the project to load, we should never load additional projects under:/Users/matb/project/test/**but could load ones from under/Users/matb/project/other/**The text was updated successfully, but these errors were encountered: