[RFC] Native Rust support

[anthonyshew]

Turborepo now experimentally supports Rust: https://turborepo.dev/docs/guides/tools/rust

Motivation

One of the longest-standing, open requests in Turborepo is to support more language toolchains than JavaScript: #683

This RFC seeks to introduce Rust as a natively supported language in Turborepo, with Cargo as the package manager.

What drives this ask?

Monorepos can be large, and don't have to contain just one language. It is common to run a monorepo with many languages and language toolchains in it. However, this comes with the complexity of managing workflows across all of these language toolchains. Each language toolchain creates its own partition within the monorepo, and it becomes complicated to manage the interactions between each language's domain.

Turborepo users see what Turborepo offers for simplifying their JavaScript/TypeScript workflows, and want the same for all languages in their repository. The canonical ask becomes "How do make turbo run lint run all the linters for all my languages?"

Prior to this RFC, taking Turborepo across toolchains meant porting conventions of JS toolchains onto your other language toolchains. You'd have to put a package.json into your Rust workspaces for Turborepo to add it to your package graph, for example. A more verbose description of this can be found on our multi-language support documentation.

With this new experimental support, these problems go away. Turborepo will infer the Cargo workspace naturally, in the same way that it infers JavaScript/TypeScript toolchains. Once (if?) we prove that Rust support is valuable for Turborepo, we can continue expanding to other languages.

Why Rust for the first language?

vercel/turborepo itself is a mixed-language repository, JavaScript + Rust. We've felt the aforementioned pain significantly, and know how we want our repo to work if everything were Turborepo. Because of this, we could quickly dogfood and iterate with the first non-JS language in our repo.

We were able to see how this native support would help our users swiftly:

• chore: Dogfood native Cargo support in this repository #13283
• ci: Remove path-based workflow scheduling #13332
• feat: Run the Rust workspace tests through nextest via command override #13316

Dogfooding also means that coding agents were able to iterate on this experiment quickly. If something went wrong, it was able to course-correct in its own loop.

What about standalone Cargo workspaces?

Standalone Cargo workspaces are supported. Rust has excellent workspace support when using Cargo. It is true that Turborepo may only be able to bring marginal value to standalone Cargo workspaces, at a glance.

We are currently experimenting with approaches that could bring compile times down across CI machines. Compile times are a meaningful critique that exists for all Rust projects, and Turborepo could play a role in simplifying faster CI compilation.

Enabling for your Turborepo

1. Use Turborepo v2.10.6-canary.4 or higher.
   a. Note that you are still required to use the npm ecosystem to install the turbo binary.
2. Enable the feature using its Future Flag in turbo.json.

"futureFlags": {
    "experimentalCargoWorkspaces": true
  }

For more information on getting started, please see the link at the beginning of this post.

Usage

Using Turborepo for Rust should feel quite familiar to using it for JavaScript/TypeScript.

• Run turbo run build to build the binaries in your Cargo workspace.
• Run turbo run lint to run Clippy.
• Run turbo run check to run cargo check --workspace.

To learn more, please see the link at the beginning of this post.

What feedback is the Turborepo team looking for?

In short, everything. We want to hear about:

• UX improvements
• Your experience in a standalone Cargo workspace
• Your experience in a mixed-language repository - For example, vercel/turborepo is a mix of TypeScript and Rust
• Caching concerns
• Anything else?

[arthurfiorette]

Hey @anthonyshew!

We are evaluating the experimental Cargo workspace support in a mixed pnpm/Cargo monorepo and found three areas where guidance would help:

1. Cargo discovery appears to run locked, all-features metadata validation before task filtering. This means a JavaScript-only command still requires the Rust toolchain and access to private Cargo dependencies. Is that intentional? Would it be possible to use lightweight workspace discovery first and defer full Cargo validation until a selected task includes a Cargo package?

2. Some existing Rust commands require nextest, workspace exclusions, custom features, and target-specific arguments. Using experimentalTaskCommand appears to replace Cargo-derived inputs, compiler identity, environment hashing, output discovery, serialization behavior, and embedded sccache injection. Is there a planned mode for overriding the command while retaining native Cargo task I/O and compile-cache behavior?

3. What is the recommended way to select tasks by toolchain in a mixed repository? Existing JavaScript and Cargo packages commonly share task names such as build, test, and lint. Is a toolchain filter or per-toolchain task opt-out planned?

These determine whether native Cargo support can become the canonical graph for a mixed repository without requiring Rust credentials in every JavaScript-only job or maintaining large exclusion filters.

[anthonyshew]

Hey, Arthur, thanks for trying this out. I'll answer these question in kind.

1. This sounds like a bug. What you describe is how I intended for things to work. That's my fault and will let you know when fixed.

2. You should be able to retain the inferred inputs using inputs: ["$TURBO_DEFAULTS$]. While I was writing the feature, I didn't know if folks would expect to have to add that in to get the inputs back, or if they would want to have to write that line. In retrospect, it seems pretty obvious that the inputs shouldn't change just because you used a command, since its analogous to a script. I'll make this change and let you know when its fixed.

3. The toolchains can be targeted using the name of the root manifest. For example:

// ./package.json
{
 "name": "my-js-toolchain"
}

// ./cargo.toml
[workspace.metadata]
name = "my-rust-toolchain"

Given these, you'd be able to do:

turbo run lint --filter=my-js-toolchain
turbo run lint --filter=my-rust-toolchain

That was my intent, and one of two things are possible:

1. There's a documentation gap for this non-obvious behavior since you're the first person using it.
2. This is genuinely confusing behavior.

I will say right away that I'm hesitant to add a new --filter microsyntax, to filter onto toolchains when filtering on name is already right there. I'd want to see this continue to confuse people before introducing a new item of bespoke knowledge - but you might feel strongly the other way (would love to hear why if there's something I'm missing).

[anthonyshew]

Hey, @arthurfiorette, your first two gripes are fixed up now on v2.10.14-canary.2!

[TimDiekmann]

Hi!
I'm currently experimenting around with this neat feature. Several of our crates generate TypeScript declarations that a sibling TypeScript package owns and re-exports, so the JS package needs to depend on the crate. The RFC covers task-name collisions across toolchains, but not dependencies across them. Declaring the relationship as a task dependency is not enough:

// packages/js-pkg/turbo.json
{ "tasks": { "codegen": { "dependsOn": ["mycrate#build:types"] } } }

This orders execution correctly, but it creates no edge in the package graph. With only the crate changed, affectedPackages returns the crate and the synthetic workspace package — not js-pkg:

$ turbo query 'query { affectedPackages(base: "HEAD^") { items { name } } }'
  mycrate, testws

A similar issue is when utilizing turbo prune:

$ turbo prune js-pkg
Generating pruned monorepo for js-pkg in .../out
 - Added js-pkg

What would the solution to this be? Will it be possible to add dependencies across ecosystems in turbo.json? I could see this as a potential route.

[anthonyshew]

The original way you wanted this to work is now implemented in #14081 and released in v2.10.14-canary.3. You'll need to use the affectedUsingTaskInputs, which will become a default in 3.0 (so you'll be ahead of the curve!).

This was actually not specific to cross-toolchain; I'm surprised to learn that this is how this has always worked, even in just JS - and no one has ever complained about it! Should be smoother now so tasks always have the things they need.

[TimDiekmann]

Thanks a lot, @anthonyshew, that indeed helped!

It unlocked me to actually try flipping experimentalCargoWorkspaces and hit a case, where the resolution again breaks. I'll demonstrate that on an example again: a JavaScript task depends on a crate task and narrows its inputs to that tasks outputs:

// mycrate/turbo.json
{
  "extends": ["//"],
  "tasks": {
    "build:types": {
      "command": ["cargo", "test", "--features", "codegen"],
      "outputs": ["types/**"]
    }
  }
}

// js-pkg/turbo.json
{
  "extends": ["//"],
  "tasks": {
    "codegen": {
      "dependsOn": ["mycrate#build:types"],
      "inputs": [
        "$TURBO_DEFAULT$",
        { "mode": "dependencyOutputs", "globs": ["types/index.d.ts"], "from": ["mycrate#build:types"] }
      ]
    }
  }
}

$ turbo run codegen --filter js-pkg
  x Invalid inputs for task.
  | does not match any eligible dependency task node for this task:
  | "dependencyOutputs.from" contains "mycrate#build:types".
  | Add it to dependsOn or remove it from dependencyOutputs.from.

$ turbo run codegen --filter js-pkg --filter mycrate   # works
$ turbo run codegen                                    # works

So the selector is rejected only when the crate is not in the initial filter. The dependsOn edge alone works without issues, so it properly resolves to the cargo scope.
My guess is that the dependencyOutputs validation just seems to run before the scope is loaded.

happy to provide more information as required!

[anthonyshew]

Fixed in v2.10.14-canary.5!

[TimDiekmann]

That was quick, thanks @anthonyshew 🙏🏻

I hope you don't mind if I post another (smaller) finding I just did: a Cargo.lock change is not attributed to the crates whose external dependencies changed. The changed_packages_from_lockfile_contents seems to route every lockfile path except uv.lock through the JavaScript lockfile parser, but that fails on Cargo.lock, so affectedPackages reports LockfileChangeDetectionFailed. This implies, that it marks every package. I noticed that by downgrading a single crate's dependency in the workspace. Was this an oversight or is Cargo attribution not done yet?

[TimDiekmann]

And I spotted another gap, sorry 🙁 It's related to both, the Cargo.lock and pruning:
A crate's hashOfExternalDependencies depends on the workspace it is hashed in, so a pruned workspace never shares the remote cache with the full repository or with other prunes.
For reproduction, I have set up an MCVE (v2.10.14-canary.5):

// package.json
{
  "name": "repro",
  "private": true,
  "packageManager": "npm@10.9.2",
  "workspaces": ["packages/*"]
}

// packages/js/package.json
{
  "name": "js",
  "private": true,
  "version": "0.0.0",
  "scripts": {
    "build": "echo build"
  }
}

// turbo.json
{
  "futureFlags": {
    "experimentalCargoWorkspaces": true
  },
  "tasks": {
    "build": {}
  }
}

# Cargo.toml
[workspace]
members  = ["crates/a", "crates/b"]
resolver = "3"

[workspace.metadata]
name = "repro-workspace"

# crates/a/Cargo.toml
[package]
name    = "a"
version = "0.0.0"
edition = "2021"

[dependencies]
tracing = "0.1"

# crates/b/Cargo.toml
[package]
name    = "b"
version = "0.0.0"
edition = "2021"

[dependencies]
tracing = { version = "0.1", features = ["log"] }

npm install --package-lock-only
cargo generate-lockfile

turbo run build --filter a --dry-run=json | jq -r '.tasks[] | select(.taskId == "a#build") | .hashOfExternalDependencies'
# d27edfd627c20f6e   Cargo.lock: tracing -> log, pin-project-lite, tracing-attributes, tracing-core

turbo prune a js --out-dir ../pruned && cd ../pruned
turbo run build --filter a --dry-run=json | jq -r '.tasks[] | select(.taskId == "a#build") | .hashOfExternalDependencies'
# 6d0c9bac65e60322   Cargo.lock: tracing -> pin-project-lite, tracing-attributes, tracing-core

a never enables the log feature. The full lock file carries the workspace-unified edge between tracing and log, the pruned lockfile for b resolves it without it. In the full workspace, a#build and b#build gat the same external hash.

I appreciate this might be a tricky issue to solve. I wonder if the feature-resolved closure of the crate could provide the fingerprint, or if it could be carried over from the unpruned lock file during the prune step? Might be easier than trying to get cargo generate-lockfile generate a wrong lockfile (as I think the lockfile is actually correct).