[pull] canary from vercel:canary #568
Open
+1,495,809
−929,048
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}
### What? Use a semaphore to limit the number of concurrent fs operations to 256. Replace some tokio fs indirection with normal std::fs methods.
`readyErrors` seems to be the value that we're using to actually display the errors in the overlay, while `state.errors` seems to often contain duplicates. This causes a drift in the number of errors reported in the overlay vs the indicator. We should use the same source of truth for both.
Ensures the subsequent steps don't fail on a missing file. <!-- 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 # -->
This was available on the old memory backend, this ports it to the new backend, which is important now that it's the default. Plus, the code's cleaner now that the trait resolution hack I had was cleaned up in #75214!
### What Fixes the mismatch between docs and the feature code, aligning with docs and other properties in logging option.
Ensures swc/turbopack don't fail to load in CI. <!-- 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 # -->
Enable them here as well
) If we uniquely own the only reference to an `RcStr`, `into_owned` should just unwrap the `Arc` and return the inner value instead of cloning it. It seems this optimization was accidentally broken at some point. `Arc::try_unwrap(arc.clone())` is always going to return the non-unique `Err` value because the `arc.clone()` will always set the refcount >= 2. This makes `RcStr::into_owned` significantly faster for large strings that we own a unique `Arc` for. Includes a unit test and a benchmark to prevent regressing. ``` RcStr::map/unique time: [17.311 ns 17.539 ns 17.797 ns] change: [-97.932% -97.855% -97.778%] (p = 0.00 < 0.05) Performance has improved. Found 10 outliers among 100 measurements (10.00%) 4 (4.00%) high mild 6 (6.00%) high severe RcStr::map/cloned time: [1.0424 µs 1.0529 µs 1.0655 µs] change: [-1.2209% +1.1551% +3.8229%] (p = 0.39 > 0.05) No change in performance detected. Found 22 outliers among 100 measurements (22.00%) 9 (9.00%) low severe 7 (7.00%) low mild 2 (2.00%) high mild 4 (4.00%) high severe ```
Since I will be modifying the stack frame code, I would like to consolidate (unfork) them first to avoid double handling.
when using use-cache standalone we don't need the dev warmup render becuase it is for addressing environment names of Prerender in DIO mode. This fixes a bug where rejected promises from cookies appeared in server logs when use cache was enabled without dynamicIO.
Previously when we removed this from the response we only did so for requests that flowed through middleware and static handlers. We should ensure it's filtered in `sendResponse` as well. The header is only needed internally.
This is a follow-up to: #75261 Tracking issue for these follow-ups: https://linear.app/vercel/issue/PACK-3828/argument-filtering-follow-ups
…75607) ### What? The `default` cache handler does not use the computed size of the ReadableStream for LRU evicting. Because the default size is `1`, this ends up allowing up to 50M items in the LRU cache. ### How? - We now pass `(entry) => entry.size` as a second parameter to the `LRUCache` constructor - We also adjust the LRUCache size to 50MB instead of 50M bytes to be more consistent with other places (e.g. the static paths cache). --------- Co-authored-by: Hendrik Liebau <[email protected]>
Today, when editing server components that use `"use cache"` functions, only updates to the uncached parts of the component will be reflected in the rendered result after the HMR refresh was applied. Any cached functions/components will show the same content as before the edit. This is problematic when a function with a `"use cache"` directive is edited. In this case, the edits won't be applied, and stale content is shown in the browser, until the dev server is restarted. With this PR, we are now including an HMR refresh hash in the cache key for all `"use cache"` functions. This ensures that those functions are revalidated when a server component is edited, which avoids showing stale content. However, while the `"use cache"` functions are revalidated during the HMR refresh, we will still restore any fetches inside of `"use cache"` from the [server components HMR cache](https://nextjs.org/docs/app/api-reference/config/next-config-js/serverComponentsHmrCache) (unless their input changed because of the edit). For Webpack, a real content hash is used, which means that if an edit is reverted to a prior edit, the previously cached data will be retrieved from the cache. For Turbopack, the HMR hash is currently just an incrementing counter, which may be improved in a follow-up PR. closes NAR-65
…5587) ### What? Use `swc_atoms::Atom` instead of `String` in `next-swc`. ### Why? `Atom` does not allocate if another instance has the same value, meaning that `clone()` is a single atomic operation. But `String` allocates regardless of any other occurrence.
…es to use the new synchronous APIs (#75547) This is a follow-up to #75055. After #75055, the async methods are just facades around the synchronous versions, to avoid breaking the API. I made this PR using: ``` sg run -p 'ResolvedVc::try_sidecast::<$$$TY>($$$ARGS).await?' -r 'ResolvedVc::try_sidecast_sync::<$$$TY>($$$ARGS)' -U sg run -p 'ResolvedVc::try_sidecast($$$ARGS).await?' -r 'ResolvedVc::try_sidecast_sync($$$ARGS)' -U sg run -p 'ResolvedVc::try_downcast::<$$$TY>($$$ARGS).await?' -r 'ResolvedVc::try_downcast_sync::<$$$TY>($$$ARGS)' -U sg run -p 'ResolvedVc::try_downcast($$$ARGS).await?' -r 'ResolvedVc::try_downcast_sync($$$ARGS)' -U sg run -p 'ResolvedVc::try_downcast_type::<$$$TY>($$$ARGS).await?' -r 'ResolvedVc::try_downcast_type_sync::<$$$TY>($$$ARGS)' -U sg run -p 'ResolvedVc::try_downcast_type($$$ARGS).await?' -r 'ResolvedVc::try_downcast_type_sync($$$ARGS)' -U ``` Delete the implementation of the non-sync methods, and then: ``` sg run -p 'ResolvedVc::try_sidecast_sync' -r 'ResolvedVc::try_sidecast' -U sg run -p 'ResolvedVc::try_downcast_sync' -r 'ResolvedVc::try_downcast' -U sg run -p 'ResolvedVc::try_downcast_type_sync' -r 'ResolvedVc::try_downcast_type' -U ``` Then rename the methods implementations in `resolved.rs` to match.
### What? ### Why? `swc_atoms::Atom` is better for repeatedly used strings.
…ope (#75505) `Rope` is an immutable type, and gets stored in a `Vc`. Like we do for other celled types, we should shrink it before storing it inside of `Arc`s.
…stead (#75530) The fxhash crate hasn't been updated in 7 years, the rust-hash crate is actively maintained. We were using an awkward mix of both, unify on just using rustc-hash.
## Why? If an issue has the `stale` label, let's not run Nissuer.
Refactor in preparation for stack frame request batching. This separates the stack frame logic from the API layer, which allows me to reuse the logic for next batching API.
…75952) Noticed this while adding bundle layers to Pages router. The telemetry Webpack plugin is picking up these features but then we're not recording them properly.
This is required for when we start using layers in Pages Router.
Most functions in `next/cache` don't work on the client, and produce confusing error messages when called there. It's better to just ban them at compile time. NOTE: For legacy/compat reasons, we're allowing `unstable_cache` and `unstable_noStore`, since they don't currently throw when called.
) This ensures we don't accidentally return the sourcemap for the server code of a given file when a stackframe was created in the browser. The Server vs Client case could be distinguished separately but not if we're dealing with externals in Edge and Node.js. We have to use the native `findSourceMap` for those case. There's probably a valid factoring where we ask the correct compilation to avoid ambiguity but the bundler is really just a perf optimization. E.g. in `next start` and prerender of `next build` we don't have access to the bundler so native `findSourceMap` has to work. It's not needed for Turbopack since source URLs are already unique it seems. The actual test is in #75863 which wouldn't work without this change.
seems like we're not emitting any errors tagged with a `NEXT_RSC_ERR_` code anywhere, so this is dead code now
This updates the Rust toolchain to nightly-2025-02-12. It required: - Removing `#![feature(async_closure)]` - Removing `#![feature(map_many_mut)]` and renaming `map.get_many_mut()` to `map.get_disjoint_mut()` - Adding a range argument to `vec.extract_if()` Test Plan: CI
…75785) ### Why? When fails to find the file to open in the editor, the middleware returned `No Content` with 204 status. This caused to silently fail the open editor behavior. ### How? - Added 404 not found state for when the target file does not exist. Closes NDX-792 --------- Co-authored-by: Jiachi Liu <[email protected]>
These jobs were failing because they first attempt to open the existing file to compare, and there was no pre-existing file: https://github.com/vercel/next.js/actions/workflows/rspack-update-tests-manifest.yml Fixed this by running: ``` echo '{}' > /home/bgw.linux/next.js/test/rspack-dev-tests-manifest.json echo '{}' > /home/bgw.linux/next.js/test/rspack-build-tests-manifest.json node test/build-rspack-dev-tests-manifest.js node test/build-rspack-build-tests-manifest.js ``` 
<!-- 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 # -->
Mostly clarifying where we deal with source URLs instead of paths and remove some redundant or unused code.
This PR synced style with the re-redesign. | Before | After | |--------|--------| |  |  | |  |  | Closes NDX-811
Updated the Node.js inspector icon and the sizes of icons from 16 to 14. | | Enabled | Disabled | |--------|--------|--------| | Light |  |  | | Dark |  |  | Closes NDX-642
This was already implemented in the middleware for Turbopack but absent when Webpack was used. We now always prefer the native `findSourceMap` over invoking Webpack's API. This way stackframes from externals are now properly sourcemapped (and therefore ignore-listed) Notice how the `react-server-dom-webpack...` stackframe (`console.error` method) wasn't ignore-listed before. Before:  After: 
- `newDevOverlay: true` by default (enables experimental React builds on canary until owner stacks progress further) - `run-tests` now sets the env var for tests that were relying on it for forking behavior - PPR runners now run with the flag disabled to help catch regressions in the old overlay until we remove it - Fixed a number of tests that had outdated snapshots or missed forking behavior because they weren't running in CI - Disabled a test that was failing in Turbopack + Experimental React that is unrelated to the overlay (see: #75989) --------- Co-authored-by: devjiwonchoi <[email protected]>
…75768) When the Next.js version is stale and revealing the docs for the version staleness, remove `(learn more)` and modify the info text to be clickable. ### Light https://github.com/user-attachments/assets/cec6c6a1-a788-4c4d-ab20-416217b42c20 ### Dark https://github.com/user-attachments/assets/02e53d84-146b-4508-b877-586a7fb0195e Closes NDX-637
This fixes a bug with the experimental PPR debugging where it previously always failed in production because the hydration script was always invoked even when the stream was terminated early due to the debugging state. <!-- 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 # -->
This handles when the rewrite destination is not a valid URL (as it's a pattern anyways, containing characters like `:` for patterns like `:subdomain.google.com` which wouldn't be valid). This uses the existing escaping behaviour to extract the url parts. Fixes #75956
…#75984) ### What? When you enable both Turbopack, and the new dev overlay, you will see that the dev overlay is frozen and the network tab shows that it is fetching the stack frames API indefinitely. ### Why? During our migration to the new development overlay, we implemented a refactor to ensure that logic for handling runtime errors is executed consistently, even in the case of build-time errors. This change involves invoking the getErrorByType function for build errors. However, this function attempts to retrieve stack frames for the build-time error, inadvertently triggering Turbopack to initiate a rebuild. Once Turbopack completes the rebuild process, it dispatches a Hot Module Replacement (HMR) event to indicate the presence of a new error. This event prompts getErrorByType to attempt fetching the stack frames again, which in turn causes Turbopack to rebuild once more. This creates an endless loop of rebuilding and error signaling. You can repro it by running ``` __NEXT_EXPERIMENTAL_NEW_DEV_OVERLAY='true' TURBOPACK=1 pnpm testonly-dev test/development/acceptance-app/editor-links.test.ts ``` with the test file change in this PR. (Important to add that. Otherwise the test would still complete successfully) ### How? Do not run the runtime error logic for build errors. Closes NDX-816
### Why? Since the `hello-world` app is also used for the default debugging app, I used to add a config when testing a relevant feature and removed it after. Hence, just added a config. https://github.com/vercel/next.js/blob/959a31214341d1ea00c0f00bcc8fc6f6a9c7b6fc/.vscode/launch.json#L11
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 : )