[pull] canary from vercel:canary #386
Merged
Conversation
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
…#83920) This has been disabled for a long time and is superceeded by ImportTraces
…83848) ### What? Replace run_once calls with `run` to avoid task memory overhead.
This auto-generated PR updates the production integration test manifest used when testing Rspack.
This auto-generated PR updates the development integration test manifest used when testing Rspack.
### Why? When running a dev server, it currently gets interrupted when running `next build`. This is very common when using AI for app development, where it runs `next build` for whatever reason while the user is working on a dev server. ### How? This PR creates an isolated `dev/` directory inside the `distDir` to be isolated from the build, and will not be cleared out during the `next build` like the `cache/` directory. Since the cache between the dev and prod isn't shared at the moment, it makes sense to let them have separate `cache/` directories. https://github.com/user-attachments/assets/2005ba70-861c-4763-b47f-cf17c62c0571
## What
Remove the `First Used JS` and `Size` metrics from `next build` CLI output, as well as the manifest files that supported these metrics.
## Why
A recent investigation has revealed a number of bugs and longstanding known issues in the implementation.
* The metrics produced by Webpack builds for App Router don't account for layouts and parallel routes correctly.
* Not only are they not accounted for in route sizes, they are treated as distinct routes for the 'uniqueness' computation which means dependencies of a widely shared layout wouldn't be treated as 'common chunks'
* The `First Used JS by All` metric counts `.css` chunks as JS
* This happened to predominately affect turbopack reporting due the above issue in webpack (css deps of layouts don't get treated as common deps)
* In App router, client components are not accurately modeled by either toolchain
* webpack doesn't account for client components at all. Leading to consistent undercounts
* turbopack accumulates all referenced client components which is better but can be an overcount for conditionally rendered or mutually exclusive components.
* In Pages router, `next/dynamic` dependencies can confuse these metrics
Generally, if a server is using any non-trivial logic to decide what is rendered there is just no correct answer to the 'First Load JS size' question. These metrics originally came out of a collaboration with Chrome DevRel back in 2019 (maybe? first reference i think is #7194). Since then, the web has shifted to Core Web Vitals and indeed that is what we use to evaluate actual performance.
We've decided to remove the metric instead as it's misleading at this point.
See #83823 for docs updates
### What? add test case for memory leak
Retrying this... ## TODO - [x] deploy docs action - [x] verify that re-compiled deps are ok, no version regression - [x] turbopack with fumadocs errors out, why?
- [x] The big question is: do we - put this behind a flag (`nextConfig.experimental.importTypeBytes`?) - ~~put this behind a non-standard `type: "turbopack-bytes"` (currently implemented)~~ - ~~just ship it?~~ - the only "problem" is that type: "bytes" is now silently ignored if the flag is not enabled - [x] [Furthermore, `Uint8Array.fromBase64` isn't that widely supported](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Uint8Array/fromBase64#browser_compatibility). So emitting that always is questionable from a browser support standpoint. This is the output in the test: ```js module.exports = [ "[project]/turbopack/crates/turbopack-tests/tests/execution/turbopack/basic/type-bytes/input/data.bin (static bytes in ecmascript)", (ctx) => { ctx.v(Uint8Array.fromBase64("dGhpcyBpcyBzb21lIGRhdGEK")); }, "[project]/turbopack/crates/turbopack-tests/tests/execution/turbopack/basic/type-bytes/input/index.js [test] (ecmascript)", (ctx) => { "use strict"; var bytes = ctx.i( "[project]/turbopack/crates/turbopack-tests/tests/execution/turbopack/basic/type-bytes/input/data.bin (static bytes in ecmascript)" ); it("import type:bytes should work", () => { expect(bytes["default"]).toBeInstanceOf(Uint8Array); expect(new TextDecoder().decode(bytes["default"])).toBe( "this is some data\n" ); }); }, ]; ```
### What? Once tasks should read all cells strongly consistent, but `project()` was not read strongly consistent. * read project strongly consistent in project_update
The ref object wasn't passed to the hook; instead, ref.current (the value) was passed. This caused `useOnClickOutside` to be noop on initial render when ref.current was null, and only worked later because the component re-rendered with a different value. The fix ensures the hook always has access to the current DOM element whenever the effect runs. ### Before https://github.com/user-attachments/assets/baa7ea6c-9506-4f14-8950-b4e7e7abbe61 ### After https://github.com/user-attachments/assets/18c3c569-ca30-41c3-ae92-f2d3e8fcee4c
Before: <img width="2560" height="1224" alt="Bildschirmfoto 2025-09-12 um 18 47 11" src="https://github.com/user-attachments/assets/c40d2be6-f570-40b4-8a82-7b181f2de073" /> After: <img width="2560" height="1323" alt="Bildschirmfoto 2025-09-12 um 19 15 35" src="https://github.com/user-attachments/assets/b58826c4-88f0-4efb-b70a-fd384785af21" /> Not that drastic of a difference, because this is still a problem: <img width="972" height="826" alt="Bildschirmfoto 2025-09-12 um 19 15 41" src="https://github.com/user-attachments/assets/5bd63a13-27ba-468c-a0a4-e66639bc47a3" /> Technically, when calling `::reference()`, there is no need to compute the path, but `ChunkData` does that on initialization. `NEXT_TURBOPACK_TRACING=turbo-tasks pnpm next build --turbo test/production/pages-dir/production/fixture`
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
7 participants
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 : )