4 ms·

Curious about your thoughts on turbo?

no_wizard 3y ago
From my usages with it: It worked relatively well for somethings, namely builds and focused watch mode (like running watch only on apps via the build tool, e.g. vite or webpack). I don't like that they punted their remote cache to basically be "Sign up for this vercel service or read our API contract, which BTW can change without notice". It also lacks a smart workspace watch mode, which is frustrating. This is something that wireit in particular does really well. If you look at the GitHub discussions / issues for turbo, they stated that they're effectively only going to implement a watch mode when `turbopack` is ready, because they want to integrate it into turbo in some way. I don't think I had issues with the cache otherwise. You can, for instance, just keep an artifact in your CI of the turbo cache (its a `.turbo` directory in the root of your repo) and while not shared with your local, it works fine enough. It didn't have any smart masking of logged output either, so you have to be consciously aware of what gets logged to the console. Not usually an issue, but works well enough. To be honest though, developing against apps was okay, but if you needed distributed watch mode across apps and libraries (say, a design system or something) it was awful, because turbo doesn't have its own smart dependency graph based watch mode startup, you just end up starting watch mode across all your dependencies with mixed results. For instances, it would trigger builds that could easily go stale or have issues if not built in the correct order, which you completely forgo because you have to use `--parallel`[0] to use watch mode. I also had dependency chain issues with HMR due to out of band builds happening etc. You can hack around this with things like nodemon, but its really a terrible experience. It also lacked proper support for phased commands, you had to hack it via pipelines which meant you didn't get 100% unique distributed tasks, which could become an issue with caching if you aren't aware of this. (using && in a script entry is not a substitute here, and declaring dependent pipelines felt like you were doing it wrong, not to mention, added overhead in some scenarios) All in all, it was fine, but I like the wireit model a bit better. Turbo also does nothing around module boundary enforcements. This is one thing NX and Rush do well if you use tags. wireit doesn't have this concept on a allow / deny level, but it does have it on a explicit dependency declaration level. Turbo has neither. I'm a bit wary of Vercel. They way they treat their open source projects and community feedback sometimes give me pause. I'm sure they're great people doing their best, I have concerns the same as I do with Google here. [0]: https://turbo.build/repo/docs/reference/command-line-reference/run#--parallel https://turbo.build/repo/docs/reference/command-line-referen...

From my usages with it: It worked relatively well for somethings, namely builds and focused watch mode (like running watch only on apps via the build tool, e.g. vite or webpack). I don't like that they punted their remote cache to basically be "Sign up for this vercel service or read our API contract, which BTW can change without notice". It also lacks a smart workspace watch mode, which is frustrating. This is something that wireit in particular does really well. If you look at the GitHub discussions / issues for turbo, they stated that they're effectively only going to implement a watch mode when `turbopack` is ready, because they want to integrate it into turbo in some way. I don't think I had issues with the cache otherwise. You can, for instance, just keep an artifact in your CI of the turbo cache (its a `.turbo` directory in the root of your repo) and while not shared with your local, it works fine enough. It didn't have any smart masking of logged output either, so you have to be consciously aware of what gets logged to the console. Not usually an issue, but works well enough. To be honest though, developing against apps was okay, but if you needed distributed watch mode across apps and libraries (say, a design system or something) it was awful, because turbo doesn't have its own smart dependency graph based watch mode startup, you just end up starting watch mode across all your dependencies with mixed results. For instances, it would trigger builds that could easily go stale or have issues if not built in the correct order, which you completely forgo because you have to use `--parallel`[0] to use watch mode. I also had dependency chain issues with HMR due to out of band builds happening etc. You can hack around this with things like nodemon, but its really a terrible experience. It also lacked proper support for phased commands, you had to hack it via pipelines which meant you didn't get 100% unique distributed tasks, which could become an issue with caching if you aren't aware of this. (using && in a script entry is not a substitute here, and declaring dependent pipelines felt like you were doing it wrong, not to mention, added overhead in some scenarios) All in all, it was fine, but I like the wireit model a bit better. Turbo also does nothing around module boundary enforcements. This is one thing NX and Rush do well if you use tags. wireit doesn't have this concept on a allow / deny level, but it does have it on a explicit dependency declaration level. Turbo has neither. I'm a bit wary of Vercel. They way they treat their open source projects and community feedback sometimes give me pause. I'm sure they're great people doing their best, I have concerns the same as I do with Google here. [0]: https://turbo.build/repo/docs/reference/command-line-reference/run#--parallel https://turbo.build/repo/docs/reference/command-line-referen...