Currently we invoke the revalidate request directly in the current
server when `res.revalidate()` is called. However app needs to be
rendered in a separate worker so this results in an error of React. This
PR fixes it by sending the request via IPC so the main process will
delegate that to the correct render worker.
Closes#48948.
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.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
The `WebSocket` constructor exposed by `undici` is not working against some db connections.
That can be considered kind of expected since `undici` docs is saying it's experimental.
We're working into isolate the issue and report at `undici` repository, but for now, let's just use `ws` for all the node versions.
This PR:
* Adds more config keys that should be supported or can be ignored
* Cleans up supported key checking and allows nested keys that aren't experimental
* Removes logging for "only supported options" since the list is much longer now
## What?
Changes the logic for running node-file-trace to no longer rely on
parsing the webpack request. Instead using the module metadata set in
each loader to generate the path.
## How?
The `route` metadata is already provided on all entry loaders since I
added `preferredRegion` support, this can now leverage `route` as well
to generate the required path.
<!-- 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 renames `experimental.experimentalReact` as
`experimental.serverActions` and makes it a hard compilation error if
it's not set but detected server actions.
### What?
This PR fixes middleware's edge-chunks not being copied in copyTracedFiles.
### How?
Merging its files' handling with other pages' ones.
### Note
I also want to exclude `process.turbopack` from the unsupported APIs list by checking if `key === 'turbopack'` in `createProcessPolyfill` and `warnForUnsupportedProcessApi`, but I want to have some opinion on this first as I don't know if `process.turbopack` works with the Edge runtime.
### What?
This fixes `next-types-plugin` causing Typescript to complain about CommonJS files importing ESM ones when `"type": "module"` is set but `experimental.typedRoutes` is not enabled.
### How?
Always create a `.next/types/package.json` with `"type": "module"` instead of only doing so when `experimental.typedRoutes` is enabled.
Fixes#49004
This PR adds `position: absolute` to the router announcer container so
it won't affect the layout of siblings / parents.
Closes#48087.
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
This PR does three things:
- Vendors the package `react-server-dom-webpack@experimental` as
`react-server-dom-webpack-experimental` similar to React and React DOM
- Upgrades all vendored React packages
- Re-lands the `experimentalReact` flag to switch between `@next` and
`@experimental` channels of React for app dir.
Fix NEXT-926.
### What?
fixes handling of GlobalError interop
adds a test case for client component bug
### Why?
app dir client component interop is broken
### Turbopack changes
* https://github.com/vercel/turbo/pull/4597 <!-- Tobias Koppers - add
rspack to our benchmark suite -->
* https://github.com/vercel/turbo/pull/4761 <!-- Tobias Koppers - Do not
use interop logic on proxy modules -->
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.
When we enable `webpackBuildWorker` this module level `const apiRouteWarnings = new LRUCache({ max: 250 })` will be created in 3 workers, so users will see 4 outputs (last one is static optimization):
<img width="740" alt="CleanShot 2023-04-29 at 20 20 38@2x" src="https://user-images.githubusercontent.com/3676859/235318861-2ec12e30-70b2-4b56-8a2e-df08d130c349.png">
This PR fixes that and now there's only 1.
### 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
