[pull] canary from vercel:canary #2674
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
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
Follow-up from #81134 updating the email used in commit messages as well.
… synchronously available. (#81090) ### Remove some unnecessary awaits now that FileSystemPath is synchronously available. ### What? * Remove `async` from `ContextCondition::matches` simplifying the implementation and eliminating a bunch of temporary allocations * Remove some unnecessary FileSystemPath clones * Remove recursion from `resolve::base_options` this function really just wants the FileSystem::root so require that instead * Share the same same `cell` for most of the node externals ### Why? Noticed this while reviewing the `resovle` codebase. I expect them to by negligible perf wins, but wins nontheless
The front-sync job has been running directly have new versions are published, but deployment tests only run after a release as well. This PR runs the front-sync job after the deployment tests. There is a new input on the workflow the front-sync triggers to immediately close the PR that gets opened in that repo that will get set to true if the tests fail. It is still beneficial to open a PR so we can more easily bisect problematic releases. See thread for discussion: https://vercel.slack.com/archives/C08V7CU57E1/p1751053430834889 <!-- 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 # --> --------- Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com> Co-authored-by: JJ Kasper <jj@jjsweb.site>
…80979) The table used for Unsupported Metadata was misplaced, so I moved it. Next.js Docs page: https://nextjs.org/docs/app/api-reference/functions/generate-metadata#unsupported-metadata The section for 'Unsupported Metadata':  The misplaced table (located a few sections down):  --------- Co-authored-by: Joseph <joseph.chamochumbi@vercel.com>
Co-authored-by: Niklas Mischkulnig <4586894+mischnic@users.noreply.github.com>
### What? Update `swc_core` to `v29.4.2` ### Why? To apply swc-project/swc#10740 and swc-project/swc#10741
### Description Add a `key` prop to the segment state boundary and change the key when we call reset, this way it will force the children re-render with the new state where the boundaries will get reset and the simulated error will be gone since we're rendering the page component now. Reseting the error boundary only won't help, it will still get the error from `getDerivedStateFromError` class method and apply to the state. This approach will reset the state group of layout-router, and ensure we keep rendering the page segment (or anything by default). ### Video https://github.com/user-attachments/assets/f6fc21da-abc1-41fc-857f-136a203f6039 Closes NEXT-4583
This auto-generated PR updates the development integration test manifest used when testing Rspack.
This auto-generated PR updates the production integration test manifest used when testing Rspack.
This auto-generated PR updates the production integration test manifest used when testing Turbopack.
This auto-generated PR updates the development integration test manifest used when testing Turbopack.
… operations (#80816) Supporting nested operations adds a lot of complexity. I have a feeling it's partially responsible for some of the lifetime stuff here. It doesn't look like it's actually needed? Sanity checked with: ``` cargo check --features turbo-tasks-backend/lmdb ```
- Renamed `ReducedGraphs` to `GlobalInformation`, these graphs never ended up getting reduced - Simplify and rename `VisitClientReference`, as its only remaining use is finding server entries (layout segments), and not client references anymore.
It's dead, Jim!!
…81152) Ensure the segment explorer is enabled when enabling the new panel UI is enabled
Simplify some of the static macro variables by moving them into their only callsites. Delete dead `ident` factories Just a tiny cleanup motivated by reading through the `registry` codegen and realizing that many of the `ident`s aren't needed.
…_transaction` (#80822) Following the removal of the other `transaction` and `lower_read_transaction` callsites in #80816... If `ExecuteContextImpl::transaction` is inlined into `ExecuteContextImpl::restore_task_data` (the only remaining callsite), we no longer need `lower_read_transaction` and its crimes against Rust lifetimes. Sanity checked with: ``` cargo check --features turbo-tasks-backend/lmdb ```
… `NextTurboTasks` with a type alias (#80823) The `NextTurboTasks` enum existed to allow us to enable or disable persistent caching at runtime. This PR implements `BackingStorage` for `Either`, so that the complexity of this branching is moved into `turbo-tasks-backend`. This eliminates the need for the next.js and eventually other consumers (`turbopack-cli`, Utoo) to handle this branching if they want to support multiple backing storage layers. The tradeoff is that moving these branches further down in the callstack might lead to more (easily predicted) branches in the code. We can see if codspeed notices anything. **Update:** Codspeed is performance-neutral.
This step was causing the front-sync job to fail. I'm not totally sure how it was working before, some other workflow must have logged logged in at some point. This is just a debug step anyway, so I think we can delete it. **I confirmed that the next step worked just fine.** We could also add a step that runs `gh login` if we think it would actually be useful.
This updates the handling of `resolvedPathname` to handle the case we don't know the `rewroteURL` for example when it's a middleware rewrite and we can't derive it since it's fully dynamic. Since we always know the `srcPage` we can always recreate the final URL using the params which this does as it's more reliable than relying on the parsed URL as a backup. Validated against our deploy tests https://github.com/vercel/next.js/actions/runs/16014327609/job/45178072108 and https://github.com/vercel/vercel/actions/runs/16014347060/job/45178081995?pr=13509 x-ref: [slack thread](https://vercel.slack.com/archives/C093RLQ7RGC)
The previous logic relied heavily on default-fallthroughs which makes it hard to follow what alias we end up using in which bundle. The new logic has more duplication which is intended so that you think about each entrypoint. With the new factoring, some bad combinations are more obvious (e.g. `react-dom/server` in product code not using the vendored version or `react-server-dom-webpack/server` not throwing in a Client environment). Compare changing aliases to .node in #81048 (based on this refactor) vs changing it without the refactor: #80941 Fixing the bad combinations is not part of this work. We probably need to finish `react-markup` first before we get more strict with `react-dom/server` usage in Server code.
Closes https://linear.app/vercel/issue/NEXT-4560/ React now exposes Web stream APIs in their Node.js builds so we can use the Node.js builds. That enable us to use some of the Node.js goodies like `async_hooks` which is required for the React's experimental Server Requests track. ## Test plan `next-server` runtimes did not increase bundle size. We even saved some in the `app-page` entries since we no longer have to bundle Edge and Node.js versions of React Server. We can rely solely on the Node.js variant of React Server. A build of `test/e2e/app-dir/hello-world` shows no significant bundle size changes
Something may have changed in infra that causes a fallback shell revalidation instead of the expected route shell revalidation. Until this is resolved we disable the deploy test to unblock.
### What? Fix a hanging compilation in a specific case when reexports modules in a cycle. Fix reported issues for tree shaken modules
Format line format: `<segment> [<files,>]` This will help visualize the rendered segment explorer panel easier by checking the snapshot. e.g. ``` app/ [layout.tsx] parallel-routes/ [layout.tsx, page.tsx] @bar/ [layout.tsx, page.tsx] @foo/ [layout.tsx, page.tsx] ```
This PR fixed two typos that affected isHeadPartial logic.
This fixes a handful of issues including: - lovell/sharp#4393 - lovell/sharp#4382 - lovell/sharp#4398 - lovell/sharp#4374 - lovell/sharp#4417 See full list of changes lovell/sharp@v0.34.1...v0.34.3
It should be equivalent, but it's clearer that the LHS is always visited
…erse_edges_from_entries_dfs` (#81481) ## Rename `traverse_edges_from_entries_topological` to `traverse_edges_from_entries_dfs` This PR renames the `traverse_edges_from_entries_topological` method to `traverse_edges_from_entries_dfs` to better reflect its actual behavior. The method performs a depth-first search traversal rather than a topological sort. The PR also: - Updates the method documentation to clarify that it performs a DFS traversal - Makes `ClientReferenceMapType` derive `Copy` for better ergonomics - Removes unnecessary `ResolvedVc::upcast` call in client references mapping - Renames some variables for clarity (`actions` → `client_references`) - Removes unused `module_graph_for_entries` function - Adds some tests for the traversal routine. Not very interesting for this traversal but should make it easier to test future traversals. These changes improve code clarity and correctness by ensuring the method name accurately describes its behavior.
) This allows us to introduce more work unit store types with confidence. closes NAR-203
This auto-generated PR updates the development integration test manifest used when testing Rspack.
…sult (#81627) Historically anything dynamic in a prerender would result in a partially static shell that resumes at runtime. With this change, now partial shells are only possible when RSC is dynamic. If your client prerender has any IO but your RSC tree was entirely prerenderable then Next.js will produce a complete static result and not perform a resume at runtime. This simplifies how you reason about what will and wil not make a static page. It also means that anything dynamic in the client layer will only render in browser. --------- Co-authored-by: Hendrik Liebau <mail@hendrik-liebau.de>
dynamicIO does not rely on Postponing for any prerender reason. This is an experimental only API with no clear path to stailization. To make dynamicIO supportable with stable React we should eliminate use of this API. This change replaces the postpone value when aborting the resume of a prerender we want to complete even when it had a postponed state with the already existing BailoutToCSRError error subclass. We already have plumbing in place to ignore this error on the client when hydrating which is exactly what we want to achieve here.
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] (v2.0.0-alpha.1)
Can you help keep this open source service alive? 💖 Please sponsor : )