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
Sometimes when debugging performance issues with badly specified includess globs, the composite flag can be really helpful because it will enumerate all the code that you are referencing and need to put in the includes, and then you can add paths incrementally instead of just having something like **/*.ts.
There are some reasons why I'm a little bit uneasy about enabling compositeandincremental, mainly that we use Turborepo to cache package builds, and I'm a little bit worried about having two different caching mechanisms.
Similar to how --isolatedDeclarations enforces certain rules without actually affecting build output, it'd be nice if there was a way to use composite's rules without being forced to set incremental too.
📃 Motivating Example
Maybe something like:
--enforceCompositeRules
💻 Use Cases
Right now there's no real workaround, composite and incremental have to go together. You can have incrementalwithoutcomposite but you run the risk of having caching bugs.
In CI one could probably just run a typecheck with the flags turned on manually I suppose, and not use it in other contexts
The text was updated successfully, but these errors were encountered:
🔍 Search Terms
composite
incremental
composite without incremental
turborepo caching
✅ Viability Checklist
⭐ Suggestion
Sometimes when debugging performance issues with badly specified
includes
s globs, thecomposite
flag can be really helpful because it will enumerate all the code that you are referencing and need to put in theinclude
s, and then you can add paths incrementally instead of just having something like**/*.ts
.There are some reasons why I'm a little bit uneasy about enabling
composite
andincremental
, mainly that we use Turborepo to cache package builds, and I'm a little bit worried about having two different caching mechanisms.You can see this issue:
To get an idea of why it can be a problem.
Similar to how
--isolatedDeclarations
enforces certain rules without actually affecting build output, it'd be nice if there was a way to usecomposite
's rules without being forced to setincremental
too.📃 Motivating Example
Maybe something like:
--enforceCompositeRules
💻 Use Cases
Right now there's no real workaround,
composite
andincremental
have to go together. You can haveincremental
withoutcomposite
but you run the risk of having caching bugs.In CI one could probably just run a typecheck with the flags turned on manually I suppose, and not use it in other contexts
The text was updated successfully, but these errors were encountered: