Skip to content
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

A way to enforce composite's rules without using incremental #61085

Open
6 tasks done
maschwenk opened this issue Jan 30, 2025 · 0 comments
Open
6 tasks done

A way to enforce composite's rules without using incremental #61085

maschwenk opened this issue Jan 30, 2025 · 0 comments
Labels
In Discussion Not yet reached consensus Suggestion An idea for TypeScript

Comments

@maschwenk
Copy link

maschwenk commented Jan 30, 2025

🔍 Search Terms

composite
incremental
composite without incremental
turborepo caching

✅ Viability Checklist

⭐ Suggestion

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 composite and incremental, 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 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 incremental without composite 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

@RyanCavanaugh RyanCavanaugh added Suggestion An idea for TypeScript In Discussion Not yet reached consensus labels Jan 31, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
In Discussion Not yet reached consensus Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

2 participants