[pull] canary from vercel:canary #568
Open
+1,485,546
−928,008
Conversation
This file contains 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
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
… manifest (#75239) Moved `should not cause error when removing loading.js` test to flaky manifest. x-ref: [Flakiness Metrics](https://app.datadoghq.com/ci/test-runs?query=test_level%3Atest%20env%3Aci%20%40git.repository.id%3Agithub.com%2Fvercel%2Fnext.js%20%40test.service%3Anextjs%20%40test.status%3Afail%20%40test.name%3A%22app%20dir%20HMR%20should%20not%20cause%20error%20when%20removing%20loading.js%22&agg_m=count&agg_m_source=base&agg_t=count¤tTab=overview&eventStack=&fromUser=false&index=citest&start=1720817553405&end=1721422353405&paused=false)
Enable the new UI for the CI testings of existing redbox tests. There are several changes made to let the test pass, including backporting changes to the old UI or removing one from the new, and are as follows: - Added back `|` after line number in code frame ([link](#74935 (comment))) - Removed unnecessary `@` in Terminal component ([link](#74935 (comment))) - Set open overlay default value to `true` in Pages Router ([link](#74935 (comment))) - Backport displaying the first first-party call stack frame to the CallStack component ([link](#74935 (comment))) - Move the devTools component back to the error boundary ([link](#74935 (comment))) - Was moved out at #74999 (comment) Closes NDX-674 Closes NDX-687
…alidation/segment-cache-revalidation.test.ts` (#75249) ### Why? Since this test creates a mock server to fetch before creating a Next.js instance, it will fail on the deployment test due to a mismatch in the location of the server and the instance. The test did try to skip when deployed but it was after the `createNext` logic, which triggered the deployment before skipping. ### How? Move the skip before any `beforeAll` logic like creating an instance. --------- Co-authored-by: Zack Tanner <[email protected]>
<!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # -->
That only causes incomplete spans in the tracing when the Span is cached.
### What? * use raw_read_dir to avoid creating many FileSystemPaths * use raw_read_dir in resolving
**View diff without whitespace changes!** This brings the number of `AssetIdent::path` calls down from 5M to 100k ``` ### canary (de984c2695b): ~16,60GB 582.76s user 109.72s system 815% cpu 1:24.95 total 583.30s user 108.45s system 805% cpu 1:25.86 total ### plus mischnic/client-manifest-optimization: still ~16,60GB 547.70s user 105.24s system 811% cpu 1:20.48 total 550.16s user 108.14s system 782% cpu 1:24.10 total ```
#75267) ### What? Apply swc-project/plugins#392 ### Why? We should not create enormous amount of memory operations needlessly.
Allows us to remove some `any` casts and `@ts-expect-error`.
#75052) ### What? Chunk async loaders together with normal chunk items to avoid multiple chunkings and small chunks
### What? It **removes** needless allocations. ### Why? To avoid allocating memory needlessly.
### What? Reduce allocations for SWC plugins, by applying swc-project/plugins#393 ### Why? Those are actually noop so they should not allocate too much.
Co-authored-by: Jiachi Liu <[email protected]>
Fixes all issues related to the current export statement validation for app router pages, as highlighted in #75277.
…75279) The `"use cache"` directive is not compatible with the Edge runtime. When the `experimental.useCache` flag is enabled, we now emit a build error for pages with `export const runtime = 'edge'`. This is analogous to using the `experimental.dynamicIO` flag. The other route segment configs that are forbidden when `dynamicIO` is enabled, are currently still allowed for `useCache`: - `dynamicParams` - `dynamic` - `fetchCache` - `revalidate`
### What? * change turbopack-cli to new backend * avoid transient tasks in turbopack-cli
### What? NextJS should not throw `The "use server" file can only export async functions.` for type exports. ### Why? Because type exports are just a compile time abstraction.
…low local-task-based argument resolution (#75214) Removes the (now default) feature flag for local task argument resolution. With local-task based argument resolution in place, we don't need to support argument resolution in the backend, which simplifies some code.
### Why? The color contrast of the terminal violated the WCAG standard. Example: | Yellow | Blue | |--------|--------| |  |  | ### Before #### Light   #### Dark  ### After #### Light   #### Dark  Closes https://linear.app/vercel/issue/NDX-657/fix-code-frame-color-contrast
<!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # -->
Reverts #75707 canary builds timed out
### What? * use new backend in next-build-test * apply effects in next-build-test * fix Dockerfile
### What? * avoid cloning SourceMap for ignore list * shrink vec before converting to Rope * shrink Strings too * shrink source map
- Remove the last remaining `AstPath` cells - Also box a rare `CodeGen` enum variant (brings down enum size from 128 bytes to 48 bytes) - `code_gens.shrink_to_fit()` Might help memory slightly, but it's bordering on measurement noise: ``` testing against 0293c96cf32 canary b6f8743 13,75 GB TURBO_ENGINE_READ_ONLY=1 NEXT_TURBOPACK_TRACING= TURBOPACK=1 TURBOPACK_BUILD= 507.86s user 77.80s system 847% cpu 1:09.11 total TURBO_ENGINE_READ_ONLY=1 NEXT_TURBOPACK_TRACING= TURBOPACK=1 TURBOPACK_BUILD= 503.13s user 77.86s system 855% cpu 1:07.90 total uncell AstPath 3ec676f 13,7 GB TURBO_ENGINE_READ_ONLY=1 NEXT_TURBOPACK_TRACING= TURBOPACK=1 TURBOPACK_BUILD= 505.04s user 83.92s system 853% cpu 1:09.00 total TURBO_ENGINE_READ_ONLY=1 NEXT_TURBOPACK_TRACING= TURBOPACK=1 TURBOPACK_BUILD= 509.03s user 84.26s system 829% cpu 1:11.53 total ```
Potential fix for a leak reported in #74855 on older node versions (see [comment](#74855 (comment))). ### Background When running middleware (or other edge functions) in `next start`, we wrap them in an edge runtime sandbox. this includes polyfills of `setTimeout` and `setInterval` which return `number` instead of `NodeJS.Timeout`. Unfortunately, on some older node versions, converting a `NodeJS.Timeout` to a number will cause that timeout to leak: nodejs/node#53335 The leaked timeout will also hold onto the callback, thus also leaking anything that was closed over (which can be a lot of things!) ### Solution Ideally, users just upgrade to a Node version that includes the fix: - [node v20.16.0](nodejs/node#53945) - [node v22.4.0](nodejs/node#53583) - node v23.0.0 But we're currently still supporting node 18, so we can't necessarily rely on that. Luckily, as noted in the description of the nodejs issue, calling `clearTimeout` seems to unleak the timeout, so we can just do that after the callback runs! ### Unrelated stuff I did While i was at it, I also fixed a (very niche) discrepancy from how `setTimeout` and `setInterval` behave on the web. when running the callback, node sets `this` to the Timeout instance: ```js > void setTimeout(function () {console.log('this in setTimeout:', this) } ) undefined > this in setTimeout: Timeout { ... } ``` but on the web, `this` is always set to `globalThis`. Our wrapper now correctly does this. ### Testing <details> <summary>Collapsed because it's long</summary> Verifying this is kinda tricky, so bear with me... Here's a script that can verify whether calling `clearTimeout` fixes the leak by using a FinalizationRegistry and triggering GC to observe whether memory leaked or not. `setTimeoutWithFix` is a simplified version of `webSetTimeoutPolyfill` from the PR. ```js // setTimeout-test.js if (typeof gc !== 'function') { console.log('this test must be run with --expose-gc') process.exit(1) } function setTimeoutWithFix(callback, ms, ...args) { const wrappedCallback = function () { try { return callback.apply(this, args) } finally { clearTimeout(timeout) } } const timeout = setTimeout(wrappedCallback, ms) return timeout } const didFinalize = {} const registry = new FinalizationRegistry((id) => { didFinalize[id] = true }) { const id = 'node setTimeout'.padEnd(26, ' ') const timeout = setTimeout(() => {}, 0) registry.register(timeout, id) didFinalize[id] = false } { const id = 'node setTimeout as number'.padEnd(26, ' ') const timeout = setTimeout(() => {}, 0) timeout[Symbol.toPrimitive]() registry.register(timeout, id) didFinalize[id] = false } { const id = 'fixed setTimeout'.padEnd(26, ' ') const timeout = setTimeoutWithFix(() => {}, 0) registry.register(timeout, id) didFinalize[id] = false } { const id = 'fixed setTimeout as number'.padEnd(26, ' ') const timeout = setTimeoutWithFix(() => {}, 0) timeout[Symbol.toPrimitive]() registry.register(timeout, id) didFinalize[id] = false } // wait for the timeouts to run void setTimeout(() => { gc() // trigger garbage collection void registry // ...but make sure we keep the registry alive // wait a task so that finalization callbacks can run setTimeout(() => console.log('did the Timeout get released after GC?', didFinalize) ) }, 10) ``` To run it, Install the required node versions: ```bash for ver in v20.15.0 v20.16.0 v22.3.0 v22.4.0 v23.0.0; do ( nvm install "$ver" ); done ``` And run the test: ```bash for ver in v20.15.0 v20.16.0 v22.3.0 v22.4.0 v23.0.0; do ( echo '-------------------' nvm use "$ver" && node --expose-gc setTimeout-test.js echo ); done ``` The output on my machine is as follows. Note that the `node setTimeout as number` case comes up as false on the older versions (because it leaks and doesn't get finalized), but `fixed setTimeout as number` (which calls `clearTimeout`) gets released fine, which is exactly what we want. ```terminal ------------------- Now using node v20.15.0 (npm v10.7.0) did the Timeout get released after GC? { 'node setTimeout ': true, 'node setTimeout as number ': false, 'fixed setTimeout ': true, 'fixed setTimeout as number': true } ------------------- Now using node v20.16.0 (npm v10.8.1) did the Timeout get released after GC? { 'node setTimeout ': true, 'node setTimeout as number ': true, 'fixed setTimeout ': true, 'fixed setTimeout as number': true } ------------------- Now using node v22.3.0 (npm v10.8.1) did the Timeout get released after GC? { 'node setTimeout ': true, 'node setTimeout as number ': false, 'fixed setTimeout ': true, 'fixed setTimeout as number': true } ------------------- Now using node v22.4.0 (npm v10.8.1) did the Timeout get released after GC? { 'node setTimeout ': true, 'node setTimeout as number ': true, 'fixed setTimeout ': true, 'fixed setTimeout as number': true } ------------------- Now using node v23.0.0 (npm v10.9.0) did the Timeout get released after GC? { 'node setTimeout ': true, 'node setTimeout as number ': true, 'fixed setTimeout ': true, 'fixed setTimeout as number': true } ``` </details>
Our PRs were merged there
Way less turbo tasks Less CPU time, 300mb less memory. ``` testing against 0293c96cf32 uncell AstPath 77d7015 (PR below in this stack) 13,65 GB TURBO_ENGINE_READ_ONLY=1 NEXT_TURBOPACK_TRACING= TURBOPACK=1 TURBOPACK_BUILD= 505.04s user 83.92s system 853% cpu 1:09.00 total TURBO_ENGINE_READ_ONLY=1 NEXT_TURBOPACK_TRACING= TURBOPACK=1 TURBOPACK_BUILD= 509.03s user 84.26s system 829% cpu 1:11.53 total snapshot in with_modules c2c661b 13,3 GB TURBO_ENGINE_READ_ONLY=1 NEXT_TURBOPACK_TRACING= TURBOPACK=1 TURBOPACK_BUILD= 491.50s user 79.78s system 856% cpu 1:06.69 total TURBO_ENGINE_READ_ONLY=1 NEXT_TURBOPACK_TRACING= TURBOPACK=1 TURBOPACK_BUILD= 495.62s user 78.61s system 852% cpu 1:07.36 total ```
Lifts the style fix from #75718 into a separate PR. Fixes the feedback bar clipping the content:  Co-authored-by: Jude Gao <[email protected]>
…riginal stack frames (#75743) ### Why? When fetch fails to get the original stack frames, the process to get the Runtime Errors fails. The fetch will likely fail on Storybook stories. | Before | After | |--------|--------| |  |  | ### How? Correctly reject when request fails so that it may be caught at `_getOriginalStackFrame()` and return the stack frame.
Add and apply the merge multiple class names util. Closes NDX-664 --------- Co-authored-by: Jiachi Liu <[email protected]>
These TODOs are very old. Clean them up!
No significant perf impact
- Fix the `npm` command - Make it clear where to place test files - Was reported here: #71773 - Relevant Next.js code: https://github.com/vercel/next.js/blob/ae5026a0fa8cd67f434cf63cc1db7d7ee696c047/packages/next/src/experimental/testmode/playwright/default-config.ts#L13 - Make it clear that `next.onFetch` only works for external requests. - Relevant Next.js code: https://github.com/vercel/next.js/blob/d2711d22fb719131d63cbce05a6306917f3626ea/packages/next/src/experimental/testmode/playwright/page-route.ts#L34-L40
This was dead code after we removed `swc_css`
This was wrong #75693
) ## Why? To track issues that are marked "not stale," we need to explicitly add a not stale label. https://github.com/actions/stale does not use this label by default.
## What? This addresses [#68217](#68217) where middleware, incorrectly, does not run for _next/image requests. We can confirm this is not correct behavior through the explanation of middleware matchers in [docs](https://nextjs.org/docs/app/building-your-application/routing/middleware#matcher) > The matcher config allows full regex so matching like negative lookaheads or character matching is supported. An example of a negative lookahead to match all except specific paths can be seen here: > ```typescript > export const config = { > matcher: [ > /* > * Match all request paths except for the ones starting with: > * - api (API routes) > * - _next/static (static files) > * - _next/image (image optimization files) <- This means middleware **should** run for _next/image > * - favicon.ico, sitemap.xml, robots.txt (metadata files) > */ > '/((?!api|_next/static|_next/image|favicon.ico|sitemap.xml|robots.txt).*)', > ], > } > ``` ### When did this regress The regression happened here https://github.com/vercel/next.js/pull/57161/files#diff-6f4291cc2bfc5073fdca12a014011769e840ee68583db1468acef075f037015aL1245 > The diff since github isn't inlining the diff > ```diff > - let finished = await this.handleNextDataRequest(req, res, parsedUrl) > + finished = await this.handle(req, res, parsedUrl) > ``` > Note, `handle` groups calls to `handleNextDataRequest` **and** `handleImageRequest` https://github.com/vercel/next.js/pull/57161/files#diff-6f4291cc2bfc5073fdca12a014011769e840ee68583db1468acef075f037015aR1316-R1328 ### Why was this a regression Inside of `handle`, there is a new call to `handleNextImageRequest` (this fn handles image optimization). This ends up causing image optimization to run before user middleware code runs. When the image optimization completes, the server behaves as if the entire middleware pipeline is complete, which is **before** user middleware code is ran https://github.com/vercel/next.js/blob/d2711d22fb719131d63cbce05a6306917f3626ea/packages/next/src/server/base-server.ts#L1528-L1540 Said plainly, image optimization now runs in middleware. And when image optimization completes, it blocks user middleware code from running. Im going to assume this was an incorrect refactor since there did not seem to be a motivation for the behavior change in #57375 ### Solution The solution proposed is to follow the same behavior as `handleNextDataRequest`, which early returns during middleware: https://github.com/vercel/next.js/blob/d2711d22fb719131d63cbce05a6306917f3626ea/packages/next/src/server/base-server.ts#L728-L745 > Note, `handleNextDataRequest` has an extra condition that it only skips middleware requests when its not on edge. I’m going to assume this is not what we want for image optimization, since there was never an edge check for image optimization- to hedge I don’t have any knowledge on what can run on edge in this context And for confirmation that the new ```handleNextImageRequest``` (added in the regression mentioned) is truly redundant, you can confirm the image optimization happens when `invokePath` is specified in the request meta or when `'x-matched-path'` header exists (as far as my understanding goes, and based on the behavior I observed from runtime checks, these 2 cases should be exhaustive) : https://github.com/vercel/next.js/blob/d2711d22fb719131d63cbce05a6306917f3626ea/packages/next/src/server/base-server.ts#L1470-L1526 https://github.com/vercel/next.js/blob/d2711d22fb719131d63cbce05a6306917f3626ea/packages/next/src/server/base-server.ts#L1078-L1378 > what's relevant in both above snippets > ```typescript > finished = await this.normalizeAndAttachMetadata(req, res, parsedUrl) > if (finished) return > ``` > Note: it's probably optimal to not call normalizeAndAttachMetadata in the if middleware branch at all since both handlers in the function now no-op if they are handling middleware (which is guaranteed in that branch). Im not applying that change here to avoid scope of the fix, but can make the refactor upon request https://github.com/vercel/next.js/blob/d2711d22fb719131d63cbce05a6306917f3626ea/packages/next/src/server/base-server.ts#L1633-L1646 ## TLDR The problem is that image optimization runs before user middleware code, and when it completes successfully, it skips running user middleware code- which means requests to _next/image will not have middleware run for them. The solution is to not run the image optimization in middleware that caused the skip Fixes #68217 --------- Co-authored-by: Joseph Chamochumbi <[email protected]>
Errors thrown by the lint worker would only surface the error if `JEST_WORKER_ID` is present. This check was not reliably truthy in all cases (eg, when run with the vercel CLI, `JEST_WORKER_ID` wasn't present) which meant the build would fail with no helpful error message. Outside of that, it was a brittle check because if jest-worker ever changed or removed this env, or we replaced the underlying worker library, this would start failing. This updates the check to be a more explicit env variable that we control. Fixes NEXT-3994
This makes sure we properly copy the necessary files in standalone mode and node middleware is configured also adds regression test for this.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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]
Can you help keep this open source service alive? 💖 Please sponsor : )