[pull] canary from vercel:canary#1033
Merged
Merged
Conversation
) ### What? The Turbopack persistent cache directory under `.next/cache/turbopack/<version>/` is now versioned by the Next.js package version concatenated with the git short SHA, instead of `git describe`. Example: `v16.0.1-canary.13-94e9fa6` ### Why? The previous version key came from `VERGEN_GIT_DESCRIBE` (`git describe --match 'v[0-9]' --dirty`), which depends on having an annotated `v*` tag reachable from the build commit. That ties the cache version to local git tag state and breaks down for builds against forks, shallow clones, or branches without a recent matching tag. The Next.js package version from `packages/next/package.json` is the value users actually care about for cache compatibility, and it is already plumbed through to the Rust side as `ProjectOptions::next_version` (sourced from `process.env.__NEXT_VERSION`). Combining it with the git short SHA keeps per-commit cache uniqueness while removing the dependency on git tags. ### How? **Rust (`crates/next-napi-bindings`)** - `build.rs`: also emit `VERGEN_GIT_SHA` (short form) via `vergen_gitcl`. `VERGEN_GIT_DESCRIBE` is still emitted and is still used for the bug-report URL / panic log. - `src/next_api/turbopack_ctx.rs`: - New `cache_describe(next_version)` returns `format!("v{next_version}-{}", env!("VERGEN_GIT_SHA"))`. - `git_version_info` now takes the pre-built `describe` string instead of reading `VERGEN_GIT_DESCRIBE` itself. `dirty` handling is unchanged (still derived from `VERGEN_GIT_DIRTY`, still suppressed in CI), so `handle_db_versioning`'s dirty-repo behavior is preserved. - `create_turbo_tasks` takes `next_version: &str` and threads it through. - `src/next_api/project.rs`: - `project_new` passes `options.next_version` into `create_turbo_tasks`. No new field is needed on `NapiProjectOptions` — the `nextVersion` field already exists and is already populated by all three call sites. - `turbopack_database_compact` (the napi `databaseCompact` function used by `next-post-build`) gains a `next_version: String` parameter so post-build compaction targets the same versioned directory. **JS (`packages/next`)** - `src/build/swc/types.ts`, `generated-native.d.ts`, `index.ts`: update the `databaseCompact(path, nextVersion)` signature on both the native and WASM-fallback paths. - `src/cli/next-post-build.ts`: passes `process.env.__NEXT_VERSION` through to `bindings.turbo.databaseCompact`. `turbopack/crates/turbopack-cli` (the standalone Turbopack CLI) is intentionally left on `VERGEN_GIT_DESCRIBE` — it is not tied to a Next.js package version. --------- Co-authored-by: v-work-app[bot] <262237222+v-work-app[bot]@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Tobias Koppers <sokra@users.noreply.github.com>
…e-server bottom-up grouping (#93460) ### What? Speeds up the bottom-up grouping pass in `turbopack-trace-server` by removing per-span `RcStr` allocations and fixes the hash map using the correct hasher for the grouping `HashMap`. ### Why? When loading large traces, building the bottom-up graph spent measurable time (1) allocating fresh `RcStr` values from `&str` keys for every span just to use them as `HashMap` keys, and (2) hashing those keys with the default randomized hasher. Both are avoidable: the underlying spans already own `RcStr`s, and the `StringTupleRef` equivalence-based lookup needs `FxHasher` anyway because `RcStr`'s `Hash` impl only matches `&str`'s `Hash` under `FxHasher`. ### How? - Change `nice_name`/`group_name`/`args` accessors on `SpanRef` and friends to return `&RcStr` instead of `&str`. The bottom-up grouping code can now clone the existing `RcStr` (a cheap ref-count bump) instead of allocating a new one from a `&str`. - Switch the `(RcStr, RcStr) -> SpanBottomUpBuilder` map in `bottom_up.rs` to use `FxBuildHasher`. This is required for the `StringTupleRef` equivalence lookup to produce matching hashes for the owned `(RcStr, RcStr)` keys, and it also removes the overhead of the default randomized hasher. - Update the `string_tuple_ref` test to use `FxBuildHasher` accordingly. No behavior changes; this is a pure refactor for performance inside the trace viewer tool. <!-- NEXT_JS_LLM_PR -->
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )