Feat project references #549
Conversation
| @@ -1,11 +1,18 @@ | |||
| { | |||
| "extends": "./tsconfig.app.json", | |||
There was a problem hiding this comment.
I kept this extending the app config, but maybe it's better to make it extend @vue/tsconfig/tsconfig.dom.json directly? That's how I've set it up in my project, makes it easier to manage.
There was a problem hiding this comment.
Yeah, I'd argue it's better to keep production and test configs separate (and rather have them extend a common base config), so that people won't e.g. add types to tsconfig.app.json that don't belong in test files.
| "cypress/support/component.*", | ||
| "cypress/support/commands.ts" | ||
| ], | ||
| "exclude": [], | ||
| "compilerOptions": { | ||
| "composite": true, | ||
| "outDir": "./node_modules/.tmp/cypress-ct", |
There was a problem hiding this comment.
It's not strictly necessary to have the declarations output for anything but the tsconfig.app.json right now, but I think it makes sense to make them all work the same way.
There was a problem hiding this comment.
Agreed. Besides, whether or not declarations will be output will change slightly in TypeScript 5.6, see microsoft/TypeScript#32651 (comment)
|
Let's hear from @sodatea what he thinks about this setup |
| "exclude": [], | ||
| "compilerOptions": { | ||
| "composite": true, | ||
| "outDir": "./node_modules/.tmp/vitest", | ||
| "tsBuildInfoFile": "./node_modules/.tmp/tsconfig.vitest.tsbuildinfo", |
There was a problem hiding this comment.
tsBuildInfoFile can be removed since now that we set outDir, its default value will be <outDir>/<config name>.tsbuildInfo, compare https://www.typescriptlang.org/tsconfig/#tsBuildInfoFile
Same thing goes for tsBuildInfoFile in the other tsconfigs.
|
Thanks so much for picking this up, @unshame ! :) |
|
@unshame Since our conversation in #437, I have run into vuejs/language-tools#3526 with increasing frequency. Right now it blocks me from introducing project references in the frontend project at my day job. I'd therefore be hesitant to merge this PR before the upstream issue gets fixed. :\ |
|
Interesting. I do see the error in vscode: Webstorm on the other hand has no issues with it and it's using the same version of vue language server. I also don't have issues with vue-tsc, it reports the errors correctly and doesn't infer the type of the component as any: So looks like a vscode extension bug? |
|
@unshame Interesting. My coworker has been reporting issues at least in IntelliJ, though. Would you mind re-posting your comment in vuejs/language-tools#3526 together with the exact versions of vue-tsc, VSCode extension, WebStorm, WebStorm Vue extension etc.? |
|
They just released a new version of volar and vue-tsc (2.4.0) : https://github.com/volarjs/volar.js/releases/tag/v2.4.0 |
|
@messenjer vue-tsc is still at 2.0.29, see https://www.npmjs.com/package/vue-tsc . I don't know which Volar version vue-tsc 2.0.29 uses¹ but it was released ~a month ago. (¹ There are no release notes and no git tag for 2.0.29 on https://github.com/vuejs/language-tools yet.) Meanwhile, @vuejs/language-tools master updated to Volar 2.4.0 only 2 days ago. So we'll have to wait for a new vue-tsc version that uses Volar 2.4.0. In any case, let's please continue this discussion in vuejs/language-tools#3526. |
|
Since my last comments a lot has happened: One ticket has been closed, another (new) ticket is still open. Personally, I decided the remaining issue is no longer a blocker, since it only affects IDE support in minor ways and type checking is not affected. So in our project I went ahead and implemented project references throughout and until now I haven't received any major complaints from my coworkers. For create-vue the considerations might be different, though, I don't know. |
We are only using `references` in a solution-style tsconfig. According to discussions at microsoft/TypeScript#60465, such usage doesn't require `composite: true` to be set in sub-configs. Removing this field loosens the constraints on these configs that all files to be explicitly listed in `files` or `includes`. After this change, type errors in source code would only be reported twice if they're also imported by unit test specs, in constrast to always be reported twice prior to the change. I know this is not ideal yet, but it's still an improvement, and might help catch some edge cases such as vuejs#437 (comment) In the long run, we should still keep an eye on vuejs#549 (pending vuejs/language-tools#4750). Cross-referencing might be a more intuitive configuration, and should be the desirable configuration if we opt into Vitest Browser Mode.
We are only using `references` in a solution-style tsconfig. According to discussions at microsoft/TypeScript#60465, such usage doesn't require `composite: true` to be set in sub-configs. Removing this field loosens the constraints on these configs that all files to be explicitly listed in `files` or `includes`. After this change, type errors in source code would only be reported twice if they're also imported by unit test specs, in contrast to always be reported twice prior to the change. I know this is not ideal yet, but it's still an improvement, and might help catch some edge cases such as vuejs#437 (comment) In the long run, we should still keep an eye on vuejs#549 (pending vuejs/language-tools#4750). Cross-referencing might be a more intuitive configuration, and should be the desirable configuration if we opt into Vitest Browser Mode.
Description
Fixes duplicate typechecking and error reporting when running type-check with vitest or cypress component tests enabled. This should also speed up typechecking.
Adds usage of project references to vitest and cypress component test tsconfigs. Adds declaration emit to the tsconfig.app.json. Only includes test files in unit testing tsconfigs.
Fixes #437
Running
pnpm run type-checkintypescript-vitestafter:Running
pnpm run type-checkintypescript-vitestbefore (2 duplicate errors):Note: due to the fact that typescript stops checking if a project reference has errors, the errors in test files appear only after errors in the app are fixed (when running
vue-tsc, it doesn't affect how IDEs display errors). There's an upcoming typescript feature that will fix this, but I don't think it's a big deal even without the fix. Definitely better than having errors reported twice.Thanks to @codethief for the idea.
E2E tests
I didn't touch tsconfigs for e2e tests. They most likely can be setup the same way as unit tests, I don't see why they need to be in a separate folder. There are more changes that need to be made to achieve this though, that should be done in a separate PR.
The nightwatch config is the weirdest case - there is just a copy of tsconfig.app.json in it that overwrites the original one. I tried to set it up to work the same way as cypress-ct does, but looks like the vue plugin doesn't have any types, so it was giving me errors. I deleted that instead of copying the new content of tsconfig.app.json into it.