Caching? #669
-
I read Why oneRepo > Alternatives & pitfalls > Cache inconsistency. It explains what can go wrong when declaring inputs and outputs manually (as it's done in Nx and Turbo), but stops short of saying that there's a better way. Do I infer correctly that oneRepo's philosophy then is "don't cache, just use source dependencies"? That sounds good for transpilation (e.g., TypeScript), but what's the story for code generation (e.g., GraphQL Code Generator), asset transformation (e.g., gltfpack), etc.? Also, I might be missing something, but one can disable all caching in Turbo and get similar results/guarantees, right? Not saying this to diminish oneRepo, just clarifying. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Yes, that's correct.
The same. If you'd like to implement your own caching strategy for specific packages, you're always welcome to do so. For example, the Prettier and ESLint plugins use their built-in caching strategies by default.
Turbo is essentially Lerna with caching. oneRepo is an entire integrated CLI SDK that enables you to build on top of the Workspace Graph for custom workflows. |
Beta Was this translation helpful? Give feedback.
Yes, that's correct.
The same. If you'd like to implement your own caching strategy for specific packages, you're always welcome to do so. For example, the Prettier and ESLint plugins use their built-in caching strategies by default.
Turbo is essentially Lerna with caching. oneRepo is an entire integrated CLI SDK that enables you to build on top of the Workspace Graph for c…