Repository navigation
Add way force TS Server to use a specific set of tsconfig/jsconfigs #33094
Description
Search Terms
- tsconfig / jsconfig
- tsserver
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 named tsconfig.json. We only load project files exactly named tsconfig.json
Feature 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 the configure request in TS
How 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:
- If that file is part of one of the configured projects, then open it inside the project
- Otherwise load the file in the inferred/global project
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.json as 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/**
Activity
[-]Add way force TS Server to work a specific set of projects[/-][+]Add way force TS Server to work a specific set of tsconfig/jsconfigs[/+][-]Add way force TS Server to work a specific set of tsconfig/jsconfigs[/-][+]Add way force TS Server to use a specific set of tsconfig/jsconfigs[/+]sheetalkamat commentedon Aug 27, 2019
Vs uses external projects and it can contain tsconfig files .. may be we could use that approach instead..
Droseyge92 commentedon Oct 8, 2019
Users/matb/project/test/tsconfig.dev.json. This could either be configured using a server command line flag or using the configure
DanielRosenwasser commentedon Jan 24, 2020
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.
12 remaining items
lobsterkatie commentedon May 25, 2022
Any update on this? Anything any of us can do to help move this along?
fix(dev): Add placeholder tsconfigs for tests (#5169)
fix(dev): Add placeholder tsconfigs for tests (#5200)
HarTstaRx commentedon Apr 17, 2023
Ryan Cavanaugh (@RyanCavanaugh) any update on this? Is there anything we can do to make this done?
albertodiazdorado commentedon Dec 14, 2023
Bump
mccolljr commentedon Mar 7, 2024
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?
randallt21 commentedon Nov 19, 2024
just a friendly little bump
this feature would be very nice for conflicting types in different types of testing files
pbrisbin commentedon Oct 23, 2025
Here to say this is also my use-case.
In a project with both Jest and Cypress, you need
types: ["cypress"]in order to edit a Cypress test (otherwise you getcyunknown errors). But with that present, editing a Jest file errors because the types of (e.g.)expectare wrong. Cypress itself usescypress/tsconfig.json, so you can make everything run correctly (jest, cypress, and build) except tsserver, which will always only usetsconfig.jsonand so error in Cypress files.(IMO, it's this pattern of using globals instead of normal imports that is the real problem, but I doubt that's going away.)
Workarounds aren't great. I've resorted to,
In the Cypress files, just to silence the warnings; but of course this gives up all type knowledge in the editor.
I think moving the cypress tests to a completely separate project (so it gets its own top-level
tsconfig), and loading the implementation code as a package, would also work. I don't know what other downsides that would bring. I think that's what we do in larger projects at $work, but for a small project that seems too big a hammer.There was a suggestion in an issue that was closed as duplicative of this to configure a list of potential configuration locations and have
tsserverchose one by resolving their respectiveinclude/excludedirectives for the current file.This sounds complicated but would be ideal for my use-case, since
cypress/tsconfig.jsonincludes only*.cy.tsandtsconfig.jsonexcludes that. Just wanted to mention that here, to make sure the suggestion was not orphaned in the now-closed duplicate.fix for MS issue with non-root tsconfig.json
fix for MS issue with non-root tsconfig.json
fix for MS issue with non-root tsconfig.json
fix for MS issue with non-root tsconfig.json
fix for MS issue with non-root tsconfig.json
Bugs/ios crash on start (#151)
referencesto be specified vscode#238390 as a duplicate of this issue