-
Notifications
You must be signed in to change notification settings - Fork 12.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle when default project for file is solution with file actually referenced by one of the project references #37239
Conversation
…ferred project instead of referenced project
…ject is solution Fixes #36708
A solution project is a composite project with references to other projects, but no files of its own? |
@amcasey That appears to be the case, but I would appreciate confirmation as well. Also, how common is that as a pattern? |
A solution project is project with project referenes but no files on its own.. (Eg https://github.com/microsoft/TypeScript/blob/master/src/tsconfig.json) |
Note that we already handle solutions for scenarios like our own repo.. Wherein the tsconfig for compiler is in its own folder and named |
@typescript-bot pack this |
Hey @DanielRosenwasser, I've packed this into an installable tgz. You can install it for testing by referencing it in your
and then running There is also a playground for this build. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How did you identify the code paths that needed to be updated (i.e. how do you know you didn't miss one)?
Well i looked at all the calls to |
It sounds like anyone who calls |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm mildly concerned about missing a case now or in the future, but this looks correct to the extent of my ability to verify it.
Can a solution // tsconfig.json
{
"files": [],
"references": [
{ "path": "./packages/client/tsconfig.json" },
{ "path": "./packages/server/tsconfig.json" },
],
"compilerOptions": {
"noEmit": true,
"allowJs": true,
"checkJs": true,
"strict": true,
"target": "ES2019",
"module": "ESNext",
"moduleResolution": "Node",
"esModuleInterop": true,
"isolatedModules": true,
"jsx": "react"
}
} |
@kripod I think you're asking whether your client and server projects will automatically pick up those compiler options - no, they won't. If you want to inherit the configuration, you need to use |
Is this patch available in If so, then the use case described in: kulshekhar/ts-jest#1698 isn't resolved by this PR. This is relevant because |
@martaver I am not sure what you are asking here. i cloned the repo, checkout branch and opened vscode and that seems to work without reporting errors. The build steps do not use tsc so it would be hard to tell whats going on. you would need to seek help from the package that is building it. |
Hi, I want to implement the same behavior programmatically with |
How are "solution projects" useful in that example? Doesn't the language server look for the nearest PS: We would appreciate a response to #33407. I'd prefer to use an {
"include": ["src"],
"compilerOptions": {
// These options are inherited by override globs.
"moduleResolution": "node",
"strict": true
},
"overrides": [
{
"include": ["**/__tests__"],
"compilerOptions": {
"types": ["jest", "node"]
}
}
]
} |
I've tried this approach without success. See anything wrong in this gist? |
Note that without extending the top-level tsconfig.json from tsconfig.base.json, the right compiler options weren't being applied for the tests, even though they are inherited by the individual project tsconfig.jsons (react and esModuleInterop). Extending the top level one from the base solves the issue, but feels wrong... I would've thought that because each project gets the right config, the tests should've worked right. Also building works fine, but it is Jest or ts-jest causing the issue. Pretty sure this is related to - kulshekhar/ts-jest#1648 - microsoft/TypeScript#37239
Note that without extending the top-level tsconfig.json from tsconfig.base.json, the right compiler options weren't being applied for the tests, even though they are inherited by the individual project tsconfig.jsons (react and esModuleInterop). Extending the top level one from the base solves the issue, but feels wrong... I would've thought that because each project gets the right config, the tests should've worked right. Also building works fine, but it is Jest or ts-jest causing the issue. Pretty sure this is related to - kulshekhar/ts-jest#1648 - microsoft/TypeScript#37239
Note that without extending the top-level tsconfig.json from tsconfig.base.json, the right compiler options weren't being applied for the tests, even though they are inherited by the individual project tsconfig.jsons (react and esModuleInterop). Extending the top level one from the base solves the issue, but feels wrong... I would've thought that because each project gets the right config, the tests should've worked right. Also building works fine, but it is Jest or ts-jest causing the issue. Pretty sure this is related to - kulshekhar/ts-jest#1648 - microsoft/TypeScript#37239
I also could not get this to work, with roughly this setup: // tsconfig.base.json
{
"compilerOptions": {"strictNullChecks": true}
}
// tsconfig.js.json
{
"extends": "./tsconfig.base.json",
"include": ["**/*.jsx?"],
"compilerOptions": {"checkJs": true, "allowJs": true, "noImplicitAny": false}
}
// tsconfig.ts.json
{
"extends": "./tsconfig.base.json",
"include": ["**/*.tsx?"],
}
// tsconfig.json
{
"files": [],
"references": [
{ "path": "./tsconfig.js.json" },
{ "path": "./tsconfig.ts.json" }
]
} VS Code behaved as if not tsconfig were detected. |
Fixes #36708, #27372
Now when we find that the project is a solution project, we try to open referenced projects to see if we can find project that contains the opened file.