# What?
This PR just refines some of the typescript types around `nextJest`, specifically refining the argument `customJestConfig` and the return value.
### Why?
Before this PR, the return type of `nextJest` was inferred by typescript as `any` which is inaccurate and would require type casting for typescript to enable it to be used in a jest configuration written in typescript.
I didn't add an issue for this since it was so trivial, but I can do so if it would be helpful.
* Fix the `generateImageMetadata` for non dynamic routes and related
`param` matching (Found during development)
* Fix dynamic routes with number suffix `(\d)` (Fixes#48689)
### What?
Exposing `globalThis.crypto`, based on [Node.js' WebCrypto
API](https://nodejs.org/api/globals.html#crypto_1)
### Why?
Similar to `fetch`, `crypto` is a popular API that is currently not
available on `globalThis` in all active Node.js versions yet.
This can help library authors to create runtime-agnostic packages.
### How?
Node.js already has the WebCrypto API that can be imported, we just
expose it on `globalThis` in Node.js versions where this is not
available.
Closes NEXT-1063
[Slack
thread](https://vercel.slack.com/archives/C03KAR5DCKC/p1681821510191059)
Depends on https://github.com/vercel/turbo/pull/4491
This adds support for the new `output: 'export'` configuration, and
propagates the value through to our Node.js rendering code to render.
Unfortunately, we don't support page-level configs at the moment, so we
can't set a `export const config = { dynamic: 'force-dynamic' }` and
test that the export value is being received (I've manually verified it,
though).
Fixes WEB-842
The current implementation is throwing wrongly if you set a falsy JS value (like `0` or `null`)
So right now this is fail even it's a legit implementation: `process.counter = 0`
Mostly mirrors the changed made in
https://github.com/facebook/react/pull/26632 to our SWC transform. The
implementation difference is that the AST transformer only adds a
general purpose wrapper call `createServerReference(id)` from an aliased
import, so we can easily change the underlying function in the bundler.
This change only affects the client layer (when `self.config.is_server
=== false`).
Needs to be landed after another React upgrade:
https://github.com/vercel/next.js/pull/48697.
cc @sebmarkbage.
## What
We recently added the searchParams as part of the __PAGE__ key in the
router. There were still a few cases where it incorrectly checked equals
instead of startsWith.
## How
Searched for ` '__PAGE__'` in order to find the leftover cases and
changed them.
<!-- 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 or adding/fixing 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 PR implements preloading of CSS from RSC.
1. The underlying Flight protocol was extended in
https://github.com/facebook/react/pull/26502 to allow sending hints from
RSC to SSR and Client runtimes. React was updated to include these
changes.
2. We now call `ReactDOM.preload()` for each stylesheet used in a
layout/page layer
There are a few implementation details to take note of
1. we were previously using the `.browser` variant of a few React
packages. This was a holdover from when there was just browser and node
and we wanted to use the browser variant b/c we wanted the same code to
work in edge/node runtimes. React now publishes a `.edge` variant which
is like `.browser` but expects to be server only. This is necessary to
get the opt-in for `AsyncLocalStorage`.
2. Even with the above change, AsyncLocalStorage was not patched on the
global scope until after React was loaded. I moved this into a module
which is loaded first
3. The component passed to RSC's `renderToReadableStream` is not
actually part of the RSC module graph. If I tried to call
`ReactDOM.preload()` inside that function or any other function defined
inside `app-render.tsx` file it would actually see the wrong instance of
`react-dom`. I added a new export on the RSC top level export which
exposes a `preloadStyle(...)` function which just delegates to
`ReactDOM.preload(...)`. This makes the preload run in the right module
graph
~There are a couple of bugs in React that this work uncovered that I
will upstream. We may want to delay merging until they are addressed.
I'll update this comment when that is complete.~
1. ~React, during SSR, can emit a preload for a style twice in some
circumstances because late discovered stylesheets don't consider whether
a preload has already been flushed when preparing to reveal a boundary
they are within~
2. ~React, during RSC updates on the client, can preload a style that is
already in the document because it currently only looks for existing
preload links and does not consider if there is a stylesheet link with
the same href.~
~both of these issues will not break functionality, they just make the
network tab look at bit more noisy. We would expect network deduping to
prevent multiple actual loads~
The above React bugs were fixed and included now in the React update in
this PR
---------
Co-authored-by: Shu Ding <g@shud.in>
### What?
Mux reported they're experiencing a specific case where scroll wasn't
applied. I've found a bug when the first element in a layout or page,
the one that React will return from `findDOMNode`, is display: hidden.
At that point the rect is is `0` `0` `0` `0` and the current logic
assumes that means it's in the viewport as it's top `0`.
In order to fix this I've looked at a few ways:
- Scrolling to top when the element is not visible
- Scrolling to the parent element that is visible
- **Scrolling to the closest sibling (nextSibling) of the element that
is visible**
Eventually I landed on the third option after looking at the Mux case,
my reproduction, and the way vercel.com's pages leveraging App Router
are structured.
### How?
Used a while loop to check if the domNode is visible, if not we continue
to the next sibling until one that is visible is found. If none are
found we bail on resolving further.
While looking into this it highlighted that we should add a global
scroll handler in app-router too for the case where none of the
layout-routers apply scroll. With this fix that is less urgent though so
I've added a todo.
Fixes NEXT-1056
<!-- 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 or adding/fixing 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 #
-->
### What?
* support local static metadata files; opengraph-image, twitter-image,
favicon, manifest, icon, apple-icon
* support global static metadata files: robots.txt, sitemap.xml,
favicon.ico
* dynamic metadata is not yet implemented, but yields a warning
It's implemented a bit different compared to the webpack version.
All images will use the usual image machinery, so they are emitted to
output directory, content hashed and the url is shared with the same
import import in the app.
### Why?
Unsupported, and we want to have that.
### How?
see also https://github.com/vercel/turbo/pull/4692
fixes WEB-524
The prefetch method is currently an async method but there's nothing to await. It's updated out-of-band. It shouldn't return a Promise.
I also found a console.log that looked out of place.
### Why
Default font file of `@vercel/og` is not loaded, because the og package is bundled by webpack and we should external it so that `fs.readFileSync` is bundled and manged that can't be traced by nft.
### How
This PR externals `@vercel/og` so that they don't need to be bundled and files can be properly traced
Closes NEXT-1047
Fixes#48704
### What?
WEB-953.
This PR moves, bubbles up unsupported package warning from turbopack to next-core using resolve plugin. Featurewise it behaves same, however removes turbopack aware specific next.js package (`@vercel/og`) internally.
### What
For dynamic routes you might have different sitemap for different params
* Unloack using `sitemap.[ext]` in your app everywhere
* Support `generateSitemaps()` to create multiple sitemaps at the same time
### How
* Change the metadata regex to allow use sitemap in every routes
* Similar approach to `generateImageMetadata`, we make `sitemap.js` under dynamic routes to a catch all routes, and it can have multiple routes
Closes NEXT-1054
This PR changes `mutableCookies` from `RequestCookies` to a
`ResponseCookies` instance, and it now accepts extra options for each
cookie. Take a look at the tests for more details.
cc @styfle
---------
Co-authored-by: Steven <steven@ceriously.com>
Similar to #47922 but based off the latest server implementation and #48626:
> This PR implements the MutableRequestCookies instance for cookies() based on the current async context, so we can allow setting cookies in certain places such as Server Functions and Route handlers. Note that to support Route Handlers, we need to also implement the logic of merging Response's Set-Cookie header and the cookies() mutations, hence it's not included in this PR.
>
> fix [NEXT-942](https://linear.app/vercel/issue/NEXT-942)
This PR also adds the same support for Custom Routes.
cc @styfle.
fix NEXT-942, fix NEXT-941.
## What?
When investigating #48852 I found that when there's a `segmentPath` set
in the `focusAndScrollRef` it would compare that entire path with the
`segmentPath` of the layout-router. This logic works in cases where the
entire page is rendered but doesn't take into account cases where for
example a suspense boundary is triggered below the common layout.
Because of the order `useEffect` is run in we can already assume that if
a more specific match existed it would have scrolled there. As that is
not the case in e.g. #48852 it ended up opting out of scrolling
entirely. In order to fix that the logic needs to be different, it needs
to check if the layout-router's `segmentPath` matches, if it matches
every level then we can apply scrolling in that layout-router.
## How?
Implemented the opposite of the current logic, running `.every` on the
layout-router segmentPath instead of on the router provided segmentPath.
Fixes#48852
Fixes NEXT-1053
Related PR #48862
<!-- 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 or adding/fixing 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 #
-->
We were adding filling in our cleanup function after we started our server. So If we restarted while the server was starting, we would fire an empty cleanup function which would lead to the server not being cleaned up (once it starts).
The only slight issue is that it won't watch for changes while cleaning up the previous run (waiting for the server from the last run to start and finish).
fix NEXT-1052
It makes more sense to use the `FormData` from `@edge-runtime/primitives` to ensure the version and implementation are aligned, and avoid importing extra modules (as we always import the Edge Runtime).
Part of #47759 (which had been reverted twice so here we only land a part of the change), relates to NEXT-926. Thanks to #48506 we can soon switch between these two channels during runtime.
Also fixes a problem of `renderKind` (only revealed after upgrading React), it should be also based on the `match` kind.
This is currently an overhead, that we check a module's layer (`mod.buildInfo.rsc?.type === RSC_MODULE_TYPES.client`) and put all client modules in the client reference manifest, but the manifest is only used for accessing these entry modules. So here we change the util to check if it's an client entry instead.
With this change the client manifest of a test app decreased from 177 KB to 70 KB.
Ref: 5b609e264f/packages/next/src/build/analysis/get-page-static-info.ts (L50-L64)
### What?
Mux reported that their website does not scroll to hash when clicking a search result. Found it's related to `server-patch` triggering and overriding the hashFragment. That should be preserved similarly to `apply`.
### How?
handleMutable had a default of `null` instead of using the existing value. It should use the existing value.
### What?
Update `@swc/helpers` to `v0.5.1`.
### Why?
Webpack merges `@swc/helpers@v0.4.x` and `@swc/helpers@v0.5.x`, due to `resolve.alias` config in 2f6ff0dab3/packages/next/src/build/webpack-config.ts (L1070-L1072)
To workaround it, `@swc/helpers@v0.5.1` reexports from entries just like `v0.4`.
### How?
Closes WEB-948
Fixes#48593
