31–40 of 55 posts
* tasks on the root package (e.g. tsc -b that typechecks all packages)
* treat tasks such as lint:eslint, lint:pretter as a single task lint (or maybe lint:*)
These are probably niche features though.
The main page says it's for JavaScript and TypeScript codebases. Will it support other languages?
Your best bet for monorepo building across a variety of languages is Nix. If money is no object you can also make do with Bazel.
Turborepo is really good, but there are a few things I like to see implemented: * tasks on the root package (e.g. tsc -b that typechecks all packages) * treat tasks such as lint:eslint, lint:pretter as a single task lint (or maybe lint:*) These are probably niche features though.
> * tasks on the root package (e.g. tsc -b that typechecks all packages)
We are working on this as we speak! The first step is to add the ability to restrict hashing `inputs`[1] to the Turborepo `pipeline`. After that we are going to be adding root task running in the next minor release.
However, as your monorepo grows, you will likely want to move away from running tasks like tsc from the root and instead run them on a per-package basis. The reason is that tools like Bazel, Buck, Turborepo, etc. can become more incremental (and thus faster) as your dependency/task graph becomes more granular (as long as you maintain or reduce the average affected blast radius of a given change). The other argument against root tasks is that they break hermeticity and encapsulation of the package abstraction. That being said, root tasks are very useful for fast migration to Turborepo and also for smaller repos. Futhermore, we're happy to tradeoff academic purity for productivity with features like this.
> treat tasks such as lint:eslint, lint:pretter as a single task lint (or maybe `lint:*`)
You can run multiple tasks at the same time and Turborepo will efficiently schedule them at max concurrency.
turbo run eslint prettier --filter=@acme/...
However, it sounds like you like to see glob fan out of tasks. This is a really cool idea. I created a GitHub issue for it here [2] if you'd like to follow along.
Earlier quoted context omitted.
Your best bet for monorepo building across a variety of languages is Nix. If money is no object you can also make do with Bazel.
I think you can benefit from using Nix and Bazel together.[1] [1]: https://www.tweag.io/blog/2018-03-15-bazel-nix/
Earlier quoted context omitted.
> There are a huge number of mostly non-JS-specific problems that monorepo tooling eventually needs to solve: distributed build artifact and test result caching, distributed action execution, sandboxing, resource management and queuing, observability, and integration with other CI tools to name a few. Turborepo author/founder here.... I agree. I built Turborepo because existing tools weren’t meeting our needs. To sol…
Is it possible to integrate Turborepo with general-purpose monorepo build tools? Bazel, in particular? (Is Bazel designed in a way that make it impossible to do JS monorepos well?)
Turborepo is really good, but there are a few things I like to see implemented: * tasks on the root package (e.g. tsc -b that typechecks all packages) * treat tasks such as lint:eslint, lint:pretter as a single task lint (or maybe lint:*) These are probably niche features though.
Turborepo author here... > * tasks on the root package (e.g. tsc -b that typechecks all packages) We are working on this as we speak! The first step is to add the ability to restrict hashing `inputs`[1] to the Turborepo `pipeline`. After that we are going to be adding root task running in the next minor release. However, as your monorepo grows, you will likely want to move away from running tasks like tsc from the ro…
Perfect!
> However, it sounds like you like to see glob fan out of tasks.
Yes, the idea here being that I don't want to list all similar tasks (such as linting) explicitly in the turborepo config. Teams should be free to add any additional lint task if they think it's useful for them (and possibly only for them). Similar to Maven(Java) where additional goals can be bound to the standard lifecycle phases.
Well done and congrats to the Turborepo team on the launch as well as the Vercel merger, which I think is a great thing for the JS ecosystem! We now have a healthy competition between several JS domain-specific build tools bit.dev, Nx, Turborepo, and Rush. This is in addition to plugins to general purpose monorepo tooling like rules_nodejs (Bazel). I'm looking forward to the seeing the new ideas that come out from th…
Earlier quoted context omitted.
> There are a huge number of mostly non-JS-specific problems that monorepo tooling eventually needs to solve: distributed build artifact and test result caching, distributed action execution, sandboxing, resource management and queuing, observability, and integration with other CI tools to name a few. Turborepo author/founder here.... I agree. I built Turborepo because existing tools weren’t meeting our needs. To sol…
Is it possible to integrate Turborepo with general-purpose monorepo build tools? Bazel, in particular? (Is Bazel designed in a way that make it impossible to do JS monorepos well?)
It's definitely possible, but I think the practical limitations would make it too complex to reason around and maintain. You'd end up creating two separate and overlapping systems to declare dependency graphs and input sources and manage caching and execution.
I haven't yet seen a case where the two are actually interleaved. Currently at Databricks, we use Bazel to provide the correctness guarantees and interop needed for CI, and we use JS-specific tooling (non-Bazel) locally to meet our performance needs, where the usage profile is different and where we're willing to make correctness tradeoffs.
> (Is Bazel designed in a way that make it impossible to do JS monorepos well?)
There are limitations in Bazel that don't play nicely with modern JS conventions. For example, Bazel's standard sandbox is based on symlink farms, and Node.js and the ecosystem by default follow symlinks[1] to their real locations, effectively breaking sandboxing. A FUSE or custom filesystem (Google's version of Bazel takes advantage of one[2]) would be better but is not as portable. As another example, Bazel's action cache tries to watch or otherwise verify the integrity of every input file to an action, and when node_modules is 100k+ files, this gets expensive and is prone to non-determinism. Bazel does this for correctness, which is noble but results in practical performance problems. You need to do extra work to "trick" Bazel into not reading these 100k+ files each time.
The problems feel solvable to me, but not easily without adding yet more configuration options to Bazel. The influx of new JS-specific tooling is a reset to this, building the minimum viable set of functionality that the JS ecosystem specifically needs, without the burdens of being a general purpose build system.
[1] https://nodejs.org/api/cli.html#--preserve-symlinks [2] https://dl.acm.org/doi/10.1145/2854146
> Turborepo is a high-performance build system for JavaScript and TypeScript codebases. > Vercel, the well-funded front-end development platform from the team behind Next.js, today announced that it has acquired Turborepo, a high-performance build system for JavaScript and TypeScript monorepos, an increasingly popular way for organizing source code into a single repository that includes all of the necessary packages…
`nx` had alot of potential, but it falls really really short for non happy path projects when I tried integrating (this is as of 15 days ago) into a relatively simple monorepo. I really disagree with its plugin interface and the idea of separating your tests from your src folders (I don't want to litter a folder `e2e` every time I need to write some tests, just feels wrong. I also then have to publicly export certain things for testing if I'm doing it right)
In particular, I feel like using go templates to do something like `plop` does would be super nice.