This uses the new built-in progressive enhancement features of React.
These always use `multipart/form-data` atm. When one comes in that's not
a fetch, we can use `decodeAction` to get a resolved function.
This also ensures that we can test this by passing disableJavaScript to
tests. This disables JS for the context.
Fixes#49055, fixes#48918.
App dir will always require the server to run in the workers mode, so it
can keep a separate Node.js process for pages. This PR updates the
standalone server to initialize a "standalone server" (which works
similar to `start-server`), and changes the tracked files to include
Jest worker.
Adds proper `multipart/form-data` handling in the Edge runtime and fixes a bug (previously we are always using `serverActionsManifest.node`). For the form data, we just use `await webRequest.request.formData()` for now and will handle streaming later.
Fixes#48948
([repro](https://github.com/vercel/next.js/issues/48948#issuecomment-1533542001)).
When running inside a custom server with app dir, we should always opt
into the prebundled React with correct channels.
Thanks @karlhorky for help testing it!
Fixes#49169 too.
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
When using the `not-found.js` file to match missed routes, `serverCSSForEntries` will always be empty as the `ComponentMod.pages` itself doesn't contain any actual entry. We need to handle that as a special case.
Closes#48133.
For edge runtime, we're modifying `res.statusCode` in actions handler, but we didn't forward the `res` object to it, previously we're using a fake `res` `{}`. This PR fixes it so that the propery status code will be returned to the client
[slack-thread](https://vercel.slack.com/archives/C052S77L05C/p1682988777740609)
Follow up of #48867
- Statically optimize dynamic generated sitemap routes
- Previously the generated sitemap urls looks bit off
(`/route/sitemap.xml/[id]`), we polish it into `/route/sitemap/[id].xml`
in this PR
Not 100% convinced that this is the correct fix but it's the best I can
think of.
Previously, we would sometimes call location.assign()/.replace()
hundreds of times (or more) as I described in
https://github.com/vercel/next.js/issues/48438 and
https://github.com/vercel/next.js/issues/48309#issuecomment-1512290958.
Sometimes this would just make things slow but the navigation would
eventually succeed; sometimes this would just hang the browser.
Now we trigger it only once (or—for a reason I don't quite
understand—twice in dev, as you can see in the test) and never commit
that render.
This also fixes the bug I mentioned in
https://github.com/vercel/next.js/issues/48438#issuecomment-1528649776
where usePathname() and useSearchParams() would return the page we are
navigating to (even if that's an external page wholly unrelated to our
site!).
Fixes#48309, fixes#48438.
link NEXT-1028
Co-authored-by: Jimmy Lai <laijimmy0@gmail.com>
This ensures we properly handle edge runtime during build when loading pages as currently we are only check the page itself for the runtime flag although it can be nested higher up but we already have the relevant info in the middleware-manifest so we can use that during build.
Fixes:
```sh
info - Linting and checking validity of types
info - Collecting page data ..ReferenceError: self is not defined
at Object.<anonymous> (/Users/jj/dev/vercel/next.js/test/e2e/app-dir/app-edge/.next/server/app/edge/basic/page.js:1:1)
at Module._compile (node:internal/modules/cjs/loader:1254:14)
at Module._extensions..js (node:internal/modules/cjs/loader:1308:10)
at Module.load (node:internal/modules/cjs/loader:1117:32)
at Module._load (node:internal/modules/cjs/loader:958:12)
at Module.require (node:internal/modules/cjs/loader:1141:19)
at require (node:internal/modules/cjs/helpers:110:18)
at requirePage (/Users/jj/dev/vercel/next.js/packages/next/src/server/require.ts:126:10)
at <anonymous> (/Users/jj/dev/vercel/next.js/packages/next/src/server/load-components.ts:105:16)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
> Build error occurred
Error: Failed to collect page data for /edge/basic
```
* For sitemap if they're not using dynamic routes generation `generateSitemaps`, should optimize them as static sitemap
* For icons and social images, if they're not using `generateImageMetadata`, should optimize them as static path
Closes NEXT-1071
Fixes#48991
This PR renames `experimental.experimentalReact` as
`experimental.serverActions` and makes it a hard compilation error if
it's not set but detected server actions.
Closes#48807.
The issue seems to be introduced with recent React Float change, which isn't a real problem but a behavior change. Resources are layered by the `precedence` key and the style insertion logic can be simplified as "insert the new stylesheet right after the existing stylesheet in the same layer". When multiple stylesheets are inserted in the same render pass, their new order will be flipped.
This is a nice feature so we can always maintain the order of resources that might conflict.
### What?
Whenever you navigated and a page suspended through `loading` or an error happened caught by `error` in the first level of segments (e.g. `/dashboard` but not `/dashboard/settings`) scroll would not be applied. This happened because the focus and scroll handling component is rendered as part of `InnerLayoutRouter` and the Suspense / Error boundary was rendered **around** `InnerLayoutRouter`. This behavior is incorrect as we still want to immediately scroll to the place where the loading is rendered.
This PR fixes the behavior by allowing the scroll to apply to loading / error too.
### How?
Moved the scrolling component around the loading/error/innerlayout boundary and added tests.
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
### 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
* 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)
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 #
-->
### 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.
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.
Updates the name of Next.js Analytics to Next.js Speed Insights
closes ALY-579
---------
Co-authored-by: Steven <steven@ceriously.com>
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
