This PR updates the way we preload fonts. Previously we tracked which
fonts we needed to preload for each layer and rendered a `<link
rel="preload" href="..." as="font" />` tag for each preloadable font.
This unfortunately gets blocked by data fetching and we want to be able
to hint these preloads as soon as possible. Now that React support Float
methods in RSC we can use `ReactDOM.preload(..., { as: "font" })` to
implement this functionality
This PR makes the following changes
1. expose a `preloadFont` method through the RSC graph
2. expose a `preconnect` metho through the RSC graph
3. refactor the preloads generation to use `preloadFont` instead of
rendering a preload link
4. If there are no fonts to preload but fonts are being used in CSS then
a `preconnect` asset origin is called instead of rendering a preconnect
link
5. instead of emitting a data attribute per font preload indicating
whether the project is using size-adjust we now emit a single global
meta tag. In the future we may get more granular about which fonts are
being size adjusted. In the meantime the current hueristic is to add
`-s` to the filename so it can still be inferred.
In the process of completing this work I discovered there were some bugs
in how the preconnect logic was originally implemented. Previously it
was possible to get multiple preconnects per render. Additionally the
preconnect href was always `"/"` which is not correct if you are hosting
your fonts at a CDN. The refactor fixed both of these issues
I want to do a larger refactor of the asset loading logic in App-Render
but I'll save that for a couple weeks from now
Additionally, the serialized output of preloads now omits the word
anonymous when using crossorigin so tests were updated to reflect
`crossorigin=""`
Additionally, tests were updated to no longer look for the size-adjust
data attribute on preloads
Additionally, There is a note about leaving a `{null}` render in place
to avoid a conflict with how the router models lazy trees. I'll follow
up with a PR addressing this
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
### What?
Implements resolving of `runtime` and `preferredRegion` in layouts. It
will resolve from the root layout down, each layout can override
`runtime` or `preferredRegion`.
```
app
├── layout.js -> export const runtime = 'edge'
├── page.js -> Edge runtime
└── dashboard
├── page.js -> Edge runtime
└── settings
├── layout.js -> export const runtime = 'nodejs'
└── page.js -> Node.js runtime
```
Adds support for `preferredRegion`. This is similar to `export const
config = { region: ['sfo1'] }` in `pages`.
However, there is a difference. It supports `export const
preferredRegion = 'home'` and `export const preferredRegion = 'edge'`.
`home` refers to the configured default region on your deployment
platform and `edge` refers to "all regions".
### How?
I've implemented a temporary resolving in `entries.ts`.
`preferredRegion` is tracked through the entry module in webpack which
is why it's added to all the loaders that create an entry module, this
prevents having to resolve/parse again later on.
Fixes NEXT-880
Fixes NEXT-1064
Fixes#48905Closes#48933
We bumped `undici` fetch which has a minimum version of 16.8.0 so we need to make sure `next` and `create-next-app` also have the same minimum version.
Since 14.x reaches End-of-Life on [2023-04-30](https://github.com/nodejs/Release), we can drop support for 14 in the next release.
See also:
- Related to #48870
- Related #48941
### What?
In #48928 we decided to error for the missing `id` from `generateImageMetadata` and `generateSitemaps` for better dev DX. This PR also refactors the metadata image urls generation that assumbling the utils together
# 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)
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 #
-->
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
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
A change here: (#48202) 958150d
Caused a URL to be joined with `path.join`, which on Windows inserts a backslash character. Changing to `path.posix.join` fixes this.
Breaks next build on Windows when paths like `favicon.ico` are in the source dir.
Fixes#48603
When you're using `config` object with `runtime` we'll show a warning and recomment you to move to `export const runtime = ...` for runtime property as it's documented as recommended. This PR adds a error for `next build` to avoid logs are truncated during multi-workers build and you're aware of the config which doesn't take effect with seeing the error
Follow up for #48630
link [NEXT-426](https://linear.app/vercel/issue/NEXT-426)
We currently use `URLSearchParams` to represent `FormData` but it's not really the same thing. And in Node.js 16 there's no `FormData` available so we can polyfill it via Undici.
