tsc runs duplicate work #4143
-
|
I have followed the TypeScript guide and read the "main" TypeScript blog post by Jared. (I referenced the original one a couple years back from tsdx days.) Now that I'm using turbo repo though, I'm uncertain how to handle First attempt: Use "internal" TypeScript packages and include However, I think this results in duplicate work. If we have A depends on B, then B gets type-checked twice: Once during B's
Edit: I confirmed this by intentionally inserting faulty TS code and running Second (future) attempt: Therefore, it seems like we have two choices: (1) Only run Should I try out project references? I have avoided them for a while given the article. |
Beta Was this translation helpful? Give feedback.
Replies: 6 comments 3 replies
-
|
Hi @connorjs, wondering what you ended up doing with this |
Beta Was this translation helpful? Give feedback.
-
|
Shouldn't it after it has run for the package itself get a cache hit in each of the apps that list the typescript package as a dependency? |
Beta Was this translation helpful? Give feedback.
-
|
I don't think this would help if, as the handbook recommends, you're not writing |
Beta Was this translation helpful? Give feedback.
-
|
My reading of the guide and the blogpost hasn't lead me to a clear understanding of the benefits of turborepo for TypeScript monorepos. As the blogpost says:
If this is true, then the entire monorepo must be transpiled in a single pass, and there is no possibility to parallelize the task of typechecking - the TypeScript compiler must traverse the entire module graph in order to build the types necessary to check the code in the consuming application. Thus, it would appear that Turborepo doesn't really help speed up TypeScript compilation using the TypeScript package guidelines their own docs provide. Alternatively, the blogpost continues:
If my understanding is incorrect, I would love to learn otherwise! |
Beta Was this translation helpful? Give feedback.
-
|
Right, it is not optimal for sure. I am currently trying to set the exports type field to point to built d.ts files. Along with |
Beta Was this translation helpful? Give feedback.
-
|
Hey, folks, just took a look a this as I ran into it myself and verified the behavior with What I'm finding is that Just-in-Time Packages end up getting checked by their consumer. This makes sense, since the consumer is being fed raw TypeScript, so it's getting included in that program's files. Therefore, from TypeScript's perspective, those files need type checked.
If anyone here wants to check my understanding of this, please do! We can write this into the tradeoffs section of the page linked above. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I just tried this approach and I do get errors from This is because I'm not sure this solution will be the fastest for everyone but the tradeoffs of exporting |
Beta Was this translation helpful? Give feedback.
-
|
This is creating a huge issue if you have a different tsconfig for the dependent package.. When running the task in a dependent package, it uses the tsconfig of the parent package. I have created an issue #10863 |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
Hey, folks, just took a look a this as I ran into it myself and verified the behavior with
create-turbo.What I'm finding is that Just-in-Time Packages end up getting checked by their consumer. This makes sense, since the consumer is being fed raw TypeScript, so it's getting included in that program's files. Therefore, from TypeScript's perspective, those files need type checked.
create-turbouses Just-in-Time Packages, so I switched it the@repo/uipackage to be a Compiled Package to see if there would be a difference. It looks like it does! I purposefully added a type error into the@repo/uipackage and it doesn't get reported when running aturbo run type-check --filter=web --onlycomm…