You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#48189 and #35395 (comment) are really nice new additions, but ones that are incredibly limited by my inability to have VS Code be aware of the fact that some files are using a different TS Config.
Sure, I could use different TS Configs in different folders so findup resolves rules correctly; however, that's not always ideal!Imagine a typical components folder full of folders that house component source code, test files, and maybe Storybook files...
Different file suffixes and different contexts ripe for developer experience improvements; however, to actually provide different tsconfig contexts to these files, I'd need:
This is untenable. Instead, I wanted to suggest the ability to map multiple TS Configs to VS Code where in-project collisions are checked for (so no 2 tsconfigs read the same file). If there are no collisions, VS Code will choose the correct tsconfig regarding the file in view. If there are collisions, then warn that VS Code isn't certain about which tsconfig.json to use and try to fail the compiler at top-of-file.
The text was updated successfully, but these errors were encountered:
My team has the same issue.
We try to co-locate our UI tests with our product code, and each set has its own tsconfig file which cannot be shared.
I added the jest-expect-message library to be used by our tests but Visual Studio Code keeps showing a type error, even though our external TypeScript type check succeeds.
After looking at the content of tsserver.log, I can tell Visual Studio Code is using the wrong tsconfig for the test.
#48189 and #35395 (comment) are really nice new additions, but ones that are incredibly limited by my inability to have VS Code be aware of the fact that some files are using a different TS Config.
Sure, I could use different TS Configs in different folders so findup resolves rules correctly; however, that's not always ideal!Imagine a typical
components
folder full of folders that house component source code, test files, and maybe Storybook files...Different file suffixes and different contexts ripe for developer experience improvements; however, to actually provide different tsconfig contexts to these files, I'd need:
This is untenable. Instead, I wanted to suggest the ability to map multiple TS Configs to VS Code where in-project collisions are checked for (so no 2 tsconfigs read the same file). If there are no collisions, VS Code will choose the correct tsconfig regarding the file in view. If there are collisions, then warn that VS Code isn't certain about which
tsconfig.json
to use and try to fail the compiler at top-of-file.The text was updated successfully, but these errors were encountered: