mirror of
https://github.com/hanzoai/next.js.git
synced 2026-10-30 14:46:38 +00:00
7984e4ab5c
### What? Adds `--persistent-caching` and `--cache-dir` CLI flags to `turbopack dev` and `turbopack build` in the standalone `turbopack-cli` crate. ### Why? The standalone `turbopack-cli` binary (used independently of `next`) had no way to opt into the filesystem-backed persistent cache that the `next-napi-bindings` integration already supports. Without this, repeated builds always start cold — every incremental run re-computes the full task graph from scratch. ### How? **`build.rs` (new):** A Cargo build script that uses `vergen-gitcl` to emit `VERGEN_GIT_DESCRIBE` and `VERGEN_GIT_DIRTY` as compile-time env vars. These are used to key the cache by git version, matching the same approach as `next-napi-bindings`. The build script embeds the dirty state at compile time rather than runtime to avoid a git subprocess on every startup. The dirty-state caching tradeoff (explained in the build script comment): there's a narrow edge case where the tree becomes newly dirty without triggering a Cargo rebuild, but in practice this is safe — if nothing in the crate changed, the binary is semantically equivalent to a clean build, so using the HEAD hash as the cache key is correct. **`arguments.rs`:** Two new flags on `CommonArguments` (shared by both `dev` and `build` subcommands): - `--persistent-caching` — opt-in flag to enable the filesystem cache - `--cache-dir <PATH>` — override the cache directory (defaults to `.turbopack/cache` in the project root) **`dev/mod.rs` and `build/mod.rs`:** - The `Backend` type alias changes from `TurboTasksBackend<NoopBackingStorage>` to `TurboTasksBackend<Either<TurboBackingStorage, NoopBackingStorage>>` to unify the type without dynamic dispatch. - When `--persistent-caching` is set: initializes `TurboBackingStorage` via `turbo_backing_storage()`, selects `StorageMode::ReadWriteOnShutdown` for CI/short sessions and `StorageMode::ReadWrite` for interactive dev, and prints a warning if the cache was invalidated on startup. - When not set: falls back to `noop_backing_storage()` — identical behavior to before. - Respects the `TURBO_ENGINE_READ_ONLY` env var to force read-only mode. --------- Co-authored-by: Tobias Koppers <[email protected]> Co-authored-by: Claude <[email protected]>
37 lines
1.5 KiB
Rust
37 lines
1.5 KiB
Rust
use std::env;
|
|
|
|
fn main() -> anyhow::Result<()> {
|
|
println!("cargo:rerun-if-env-changed=CI");
|
|
let is_ci = env::var("CI").is_ok_and(|value| !value.is_empty());
|
|
|
|
// We use the git dirty state to disable filesystem cache (filesystem cache relies on a
|
|
// commit hash to be safe). One tradeoff of this is that we must invalidate the rust build more
|
|
// often.
|
|
//
|
|
// This invalidates the build if any untracked files change. That's sufficient for the case
|
|
// where we transition from dirty to clean.
|
|
//
|
|
// There's an edge-case here where the repository could be newly dirty, but we can't know
|
|
// because our build hasn't been invalidated, since the untracked files weren't untracked last
|
|
// time we ran. That will cause us to incorrectly report ourselves as clean.
|
|
//
|
|
// However, in practice that shouldn't be much of an issue: If no other dependency of this
|
|
// top-level crate has changed (which would've triggered our rebuild), then the resulting binary
|
|
// must be equivalent to a clean build anyways. Therefore, filesystem cache using the HEAD
|
|
// commit hash as a version is okay.
|
|
let git = vergen_gitcl::GitclBuilder::default()
|
|
.dirty(/* include_untracked */ true)
|
|
.describe(
|
|
/* tags */ true,
|
|
/* dirty */ !is_ci, // suppress the dirty suffix in CI
|
|
/* matches */ Some("v[0-9]*"), // find the last version tag
|
|
)
|
|
.build()?;
|
|
vergen_gitcl::Emitter::default()
|
|
.add_instructions(&git)?
|
|
.fail_on_error()
|
|
.emit()?;
|
|
|
|
Ok(())
|
|
}
|