Product1 publisher2 min readPublished
Turborepo puts Rust, Python and Go tasks in the same graph behind experimental flags
Version 2.11 reads Cargo, uv and go.work workspaces so a Python test can be ordered behind a Rust build in one task graph. The support ships as experimental, switched on by future flags that can still change.
The Product Desk · Product desk
What happened
- Turborepo 2.11 reads Cargo, uv and go.work workspaces to find packages and their dependency relationships, putting Rust, Python, Go and JavaScript tasks under a single CLI and one task graph.
- Dependencies can cross toolchains in turbo.json, and the release post's example holds a Django API's test task until a Rust core package has finished building.
- The language support ships as experimental and subject to change, switched on by futureFlags entries such as experimentalCargoWorkspaces and experimentalPythonWorkspaces.
- Turborepo reports Time to First Task up to 4x faster than version 2.9, benchmarked on an Apple M4 Max with 36GB of RAM across repositories of 6, 132 and 1037 packages.
- The same release starts honouring the devEngines.packageManager field, and says the top-level packageManager field will stop being supported in a future major version.
Compiled by The Product DeskSomething wrong?How this is made
Why it matters
- decision A team running Rust or Python alongside TypeScript can now weigh one runner for everything, and the deciding test is whether Cargo and uv discovery reproduces the dependency graph their existing scripts encode.
- constraint Cross-toolchain edges written today depend on flag names the maintainers have reserved the right to change, so the config is pinned to an experimental surface for as long as it stays in CI.
- capability Affectedness and Watch Mode extend to Cargo, uv and go.work packages, so an unchanged Go service can be skipped by the same filter that skips an unchanged JavaScript package.
- cost Every repo still declaring a top-level packageManager field now owes a small migration before the next major version, paid by whoever maintains the root package.json.
"Up to 4x faster" is the six-package number. Time to First Task, the gap between invoking `turbo run` and the first task starting [7], fell from 132ms on 2.9 to 34ms on 2.11 in the `create-turbo` starter [9], a ratio of 3.9 [1]. On Vercel's backend monorepo, 1037 packages, it fell from 716ms to 394ms [10]. That is 1.8x, and 322ms of wall clock per invocation [2]. The 132-package frontend repo saved 155ms [11][4].
The longer-run figure is the bigger one. Before 2.9, that 1037-package repo took 8.1 seconds to reach its first task [10], so 394ms is about 20.6 times faster [3], which is the "over 20x" the release post claims [14]. Turborepo credited 2.9 alone with up to a 96% improvement [13]. Whoever invokes `turbo` all day in a watch loop gets the 322ms back; a pipeline whose build takes minutes will not feel it.
For a mixed-language repo, the part that decides the evaluation is discovery. Turborepo says it now derives packages and their dependency relationships from Cargo, uv and `go.work` workspaces [2]. Whether that reproduces the graph your Makefiles and CI scripts already encode is checkable on a branch: turn the flags on, list the packages and the affected set for a known commit, and diff it against what your current pipeline actually builds.
The release post labels the language support Experimental and subject to change, and points questions at GitHub Discussions [6], with separate guides for Rust, Python and Go [20]. The same post says 2.11 is the first Turborepo release with zero known bugs [18], which is a statement about the issue tracker on the day three new toolchain integrations shipped.
On the JavaScript side, 2.11 recognises two more package managers, nub and aube, both of which read your existing npm, pnpm, Yarn or Bun lockfile [16]. Production pruning now drops development-only workspace packages from `turbo prune` output [17]. The upgrade itself runs through `@turbo/codemod migrate` [19].
Two questions settle this for a team with Rust or Python next to its TypeScript. First, does discovery produce the same graph your scripts assume, including the edges nobody wrote down. Second, what does reverting cost after the flags have been in CI for a month. If the answer to the second is rebuilding two pipelines, keep the cross-toolchain `dependsOn` edges [4] in as few `turbo.json` files as you can, so backing out is one diff.
What to watch
- Whether the Cargo, Python and Go future flags graduate under the same names or get renamed on the way out of experimental.