### What?
`next build` is incorrectly reporting file size stats for the root path
when using the app dir
### Why?
In #50768, the denormalization logic was removed for appDir routes, but
`pagesManifest` has the root page keyed by `/` while the actual path
will be `/index`.
### How?
This re-adds a simpler denormalize function that just replaces `/index`
with `/`.
semi-related: #42819Fixes#51692
link NEXT-1306
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
This is already the default for production build, but we are also enabling it for development. It has small perf impact as gzip takes time, but it significantly improves the disk usage and time for reading and writing to the filesystem. This is especially the case when working on a large codebase and we are transpiling and bundling more modules now.
## Background
Currently we're track all imported CSS modules by an entry, in the
client manifest:
```js
// client manifest
{
entryCSSFiles: {
'app/entry_name': {
modules: ['app/foo.css', ...]
}
}
}
```
And then, in the font manifest we track all emitted assets (fonts) by
each CSS module:
```js
// font manifest
{
app: {
'app/foo.css': [
'static/font/abc.woff', ...
]
}
}
```
These two fields are only used together by `get-preloadable-fonts.tsx`,
so it can know which font files need to be preloaded for this entry.
(Although previously we use `.modules` for something else, but it's gone
now)
## Changes
Since we only need the font assets per entry, it's unnecessary to track
these in the module level and then join them together. This PR removes
the `modules` field from the client manifest, and changes the font
manifest to directly keep the entry—font mapping.
This gets rid of one module traversal from the client manifest plugin.
An annoying issue that slows down compilation times in dev for Next is
that we might trigger compilation of a page via hover on app.
We do this because we want the same experience in production and dev and
the prefetching is important for instantaneous loading states.
The alternative in this PR is that we don't prefetch at all anymore in
dev but instead, when we handle navigation, we can force a prefetch
navigation.
The slight compromise with this approach is that you can't test
prefetching anymore in dev.
<!-- 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 #
-->
link NEXT-1317
Instead of traversing the entire client module graph twice (!), this PR
changes it to only traverse the client **entry** modules only. Because
of the way we create client entries, all client modules' _boundaries_
can be retrieved via all outgoing connections of all chunks' entry
modules, filtered by `next-flight-client-entry-loader`.
This brings down the time complexity from `2 * num_client_modules` to
`num_client_entry_modules`.
Closes#51240.
Additional notes from @timneutkens
- Removed `module.unsafeCache` as it seemed to be leaking modules across
multiple compilations, this should help with memory usage
- Changed entry-loader to have consistent module import map (sort it) to
ensure cache key is consistent
---------
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
Limit the number of Watchpack's watchers to 20 for the routing worker which runs Watchpack. By default this value is 2000 on macOS and 10000 on Windows, which can hold too much resource.
This PR fixes tree-shaking for the metadata image generation module
(e.g. `opengraph-image.js` and other conventions) when the page has
`runtime = 'edge'`.
## Details
The first step of this fix is to change this from the loader:
```js
import * as exported from "./opengraph-image.js"
```
to be necessary fields only (so the `default` export can potentially be
removed):
```js
import { alt, size } from "./opengraph-image.js"
```
To know which fields are exported, we need to load the module first via
Webpack loader's `loadModule` API and check its
`HarmonyExportSpecifierDependency` dependencies.
This is the first step to make it tree-shakable. Since we have
`./opengraph-image.js` used in another entry, the actual image API route
`opengraph-image/route.js`:
```js
import * as image from "./opengraph-image.js"
```
Webpack still treats both as the same module and generates one chunk for
it. We want to "fork" it into two modules. The technique here is to add
a noop resource query and make it:
```js
import { alt, size } from "./opengraph-image.js?__next_metadata_image_meta__"
```
So it won't be shared in the chunk (as it's a different request), and
can be concatenated inline.
However that's not enough, the inlined result will still have all
imports from our `opengraph-image.js`, including `import { ImageResponse
} from 'next/server'`. Because we can't simply add `"sideEffects":
false` in Next.js' package.json, we need a way to mark this import as
side-effect free. I went through
https://github.com/webpack/webpack/blob/main/lib/optimize/SideEffectsFlagPlugin.js
and used the same method to mark that module with
`module.factoryMeta.sideEffectFree = true`.
With all these added, the page bundle will no longer contain the
`ImageResponse` instance.
## Result
The difference is quite amazing, for the new added test (an empty Edge
runtime page with an opengrah image file) here're the before/after
metrics for the `page.js` server bundle:
Edge bundle size: 892kB → 500kB.
Build time: 26.792s → 8.830s.
### What?
Interception route rewrites are not properly parsing catch-all segments,
which leads to "missing parameter name" errors when passed to
`pathToRegexp`.
### Why?
The existing `toPathToRegexpPath` function ignores `...` and keeps it as
part of the regexp path. This means `pathToRegexp` will attempt to
handle `/foo/bar/:...baz` and `/foo/bar/:[...baz]` rather than
`/foo/bar/:baz*`
### How?
The regex used for matching the path was updated to support the dynamic
optional segment, and then we special case catch-all segments
Fixes#51784
---------
As noted in the comments, it's necessary to always add optional dependencies as missing dependencies even if they exist because they might be deleted and re-added.
Closes#51763.
Close the circle after #51104. The name "size limit" can be confusing as it could also mean the size of the Server Action function itself, so this PR changes it to `serverActionsBodySizeLimit` and makes sure it's well documented.
This adds support for matching against the user-agent header when doing rewrites client side.
Currently a rewrite like this will fail because the user-agent header is not provided, and so next.js tries to prevent infinite rewrites:
```
{
source: '/:path*',
destination: 'https://example.com/:path*',
missing: [
{
type: 'header',
key: 'User-Agent',
value: '.*(?:Electron).*'
},
],
}
```
Adding in the user-agent header allows this rewrite to pass.
Adding `nextConfig.output` to next-info output so that we could determine if users're using standalone mode if the reproduction is not clear or missing sometimes
Example output
```
Relevant Packages:
next: 13.4.8-canary.1
eslint-config-next: 13.4.8-canary.1
react: 18.2.0
react-dom: 18.2.0
typescript: 5.1.3
Next.js Config:
output: standalone
```
<!-- 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
- 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?
Add configuration options to modify the `bodyParser` size as it used to
be available in Page Router.
### Why?
Server Actions "Error: Body exceeded 1mb limit" cannot be resolved since
the body-parser limit size is hardcoded to `1mb`.
### How?
Closes NEXT-
Fixes #
-->
### What?
Add configuration options to modify the `bodyParser` size as it used to
be available in Page Router for APIs.
```js
export const config = {
api: {
responseLimit: false | '8mb'
},
}
```
Reference: [API Routes Response Size
Limit](https://nextjs.org/docs/messages/api-routes-response-size-limit)
### Why?
Server Actions "Error: Body exceeded 1mb limit" cannot be resolved since
the body-parser limit size is hardcoded to `1mb`.
```js
// /packages/next/src/server/app-render/action-handler.ts
// ...
const actionData = (await parseBody(req, '1mb')) || ''
// ...
```
Reference:
https://github.com/vercel/next.js/blob/canary/packages/next/src/server/app-render/action-handler.ts#L355
### How?
- Added option "serverActionsLimit" as `SizeLimit` type to
`config-shared.ts`
- Modified `action-handler.ts` to validate `serverActions` &
`serverActionsLimit` options in nextConfig
- Added conditional `serverActionsLimit` value and `1mb` if falsy
**Working on testing**
Fixes#49891 | #51097 | #51099
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Co-authored-by: Shu Ding <g@shud.in>
This PR addresses a problem where the `createServerReference` is using
the default condition of flight client (gets resolved to the Node
build), but we use the Edge build of flight client for SSR. This causes
2 flight clients to exist during SSR.
This removes calls for rendering files in `pages/` via the server code and relies instead relies on the bundled `routeModule` to perform the rendering.
Future cases that try to call the legacy render will hit a new:
```
Invariant: render should have used routeModule
```
Error. These cases should be reported.
## What?
Adds a default modularizeImports that ensures `lucide-react`, `@mui/icons-material`, `lodash`, and `react-bootstrap` do not cause a massive amount of modules to be compiled in development.
For example `@mui/icons-material` re-exports 10600 (10K+) modules from a single file. Even though it does not affect production bundle size it does affect build time, especially in development, and even more so when your filesystem is slow (e.g. what we're seeing on Windows).
Related issue: #48748 (not closing)
Co-authored-by: Shu Ding <3676859+shuding@users.noreply.github.com>
Request data flow in the server
```
request ---> router worker (1) ---> ipc ---> render worker app (2)
|-----> render worker pages (3)
```
When it's hitting `_next/*` unmatched routes in standalone server, it will render 404, but when you hit `_next/*` it will render app not-found as the app router is always enabled, but router worker isn't set up with require-hook for proper built-in react version, then the app-render will fail with `./server.edge` exports not found error.
We detect if it's in the render worker, then do the app paths rendering instead of directly looking up for app paths in route worker. This could avoid unexpected accesses to the app-render
Fixes#51482Fixes#50232Closes#51506
Reverts changes in #51172
fix NEXT-1260
When conflicted pages occur between app and pages server used to throw error and you need to solve the conflicts and restart the server.
This PR capture the error during files aggregation, and send to client to display the error for files confliction. This will send all the conflicts to client and it will still error until you solve all of them. But since the server is not stuck by errors, client can recover once the error is solved.
Closes NEXT-1283
The next-metadata-route-loader emitted content with `"next/server"` is still using cjs version which is not get tree-shaked on edge runtime, This PR adds a new esm entry for it and mapped it that on edge runtime so unused exports can be tree-shaked. This case happened when users are using ImageResponse from `"@vercel/og"` instead of `"next/server"`.
2nd change is adding another alias to map `@vercel/og` package to vendored og package inside next.js, this way we could merge the two package instead of bundled both of them
Fixes: NEXT-1303
changed `require.reoslve("next/dist/xxx")` to `${NEXT_PROJECT_ROOT}/xxx}` to avoid to be traced by nft.
Continuing on changes to move the rendering logic into the bundles.
- Unifies edge render functions: `appRenderToHTML` and `pagesRenderToHTML` becomes `renderToHTML`
- When an error occurs, the error module's match is used so the module's internal render can be used (easing transition away from using the server's render method)
- Improved test resiliance
### What?
Paths with interception markers adjacent to dynamic segments are not correctly parsed, which leads to the path match logic failing.
### Why?
`getParametrizedRoutes` checks for brackets but isn't expecting to receive an interception marker. For example, a path of `/photos/(.)[author]/[id]` results in the following regex:
`/^\/photos\/\(\.\)\[author\]\/([^/]+?)(?:\/)?$/`
This will not match a path of `/photos/(.)zack/1` since it retained the `[author]` brackets.
`getSegmentParam` has a similar issue when getting values for path params, though we can just skip the interception markers and go straight to the params.
Closes NEXT-1166, NEXT-1013
Fixes#48143Fixes#49614
link NEXT-1013
### What?
This is an alternative to #51330, which only support aborting the response (doesn't support back-pressure). If the client cancels the request (HMR update, navigates to another page, etc), we'll be able to detect that and stop pulling data from the dev's `ReadableStream` response.
### Why?
We want to allow API routes to stream data coming from another server (eg, AI services). The responses from these other servers can be long running and expensive. In the case the browser aborts the connection, it's critical that we stop streaming data as soon as possible.
### How?
By checking whether `response.closed` is set during the `for await (…)` iteration, we're able to detect that the client has aborted the connection. Cleanup of the `ReadableStream` is handled implicitly by the async iterator when the loop ends.
The one catch is our use of http-proxy for worker processes. It does not properly detect a client disconnecting (but does handle back-pressure). In order to fix that, I've manually added event listeners to detect the disconnect and cancel the proxied req/res pair.
Re: [WEB-1185](https://linear.app/vercel/issue/WEB-1185) (we still need back-pressure)
Fixes https://github.com/vercel/next.js/issues/50364
Fixes https://github.com/vercel-labs/ai/issues/90
### Fixing a bug
- [x] Related issues linked using `fixes #number`
- [x] 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
### What?
Currently, when the check on validating the type of `revalidate` is run,
we use the `Number` function to parse the value of `revalidate`, however
the `Number` function takes a
[`StringNumericLiteral`](https://tc39.es/ecma262/2023/#prod-StringNumericLiteral)
which doesn't allow the usage of the `_` separator to format your
numbers. This PR allows you to add numeric separators in the
`revalidate` export.
### Why?
When configuring the actual code, we should be allowed to use numeric
separators as it is a syntax that is supported by most runtimes.
### How?
A simple `replaceAll` call that removes all `_`s between digits.
Closes NEXT-1122
Fixes#49485
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
