### What
Follow up for #64294 where we could preload all the JS and CSS chunks
for `next/dynamic` component.
* Rename `preload-css` component to `preload-chunks` and remove the
filter for css chunks
* Preload JS chunks with `defer`
### Why
Preloading all the async chunks of `next/dynamic` can make rendering
more efficiently when combined with the initial chunks. Since those
chunks are splitted on client but still essential for the page
#### After vs Before
We can see the waterfall starts much earlier for the dynamic chunk
(881.8a0e88...js)
<img width="500"
src="https://github.com/vercel/next.js/assets/4800338/9bab2c32-37c3-4c7a-93e2-3aa43b2ec7c8">
<img width="500"
src="https://github.com/vercel/next.js/assets/4800338/0fba7499-bb69-41c4-ab72-e9952f3d7f68">
### What
* Remove the `private-next-app-dir` condition for
`WEBPACK_LAYERS.appRouteHandler` layer since it's not effective as the
`rule.test` will match the actual file path. App routes are actually
bundled in rsc layer atm as expected.
* Should only let shared-runtime modules working in either ssr layer or
non-layer (unbundling pages router).
* Remove the pages router context modules for app-page runtime. Still
need to keep amp-context as it's used in `head.js` and `head.js` used in
`next/image`. Not easy to remove unless we have separate implementation
of `next/image` for pages and app router
Closes NEXT-3312
### What
* Extract `buildId` and server action encryption key into environment
variables for edge to make code more deterministic
* Fixed the legacy bad env names from #64108
* Always sort `routes` in prerender manifest for consistent output
* Change `environments` to `env` in middleware manifest, confirmed with
@javivelasco this is a fine change without need to bumping the version
### Why
Dynamic variants like `buildId`, SA `encryptionKey` and preview props
are different per build, which results to the non determinstic edge
bundles. Once we extracted them into env vars then the bundles become
deterministic which give us more space for optimization
Closes NEXT-3117
Reverts vercel/next.js#65425
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
### What?
make sure children is first in loader tree to fix head css bug on client
navigation
### Why?
### How?
Fixes PACK-3028
---------
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
### What
Support `esmExternals` working in app router
### Why
`esmExternals` was disabled for app router that most of the packages are
picking up the CJS bundles for externals. This PR enables to resolve the
ESM bundle for external packages.
We have two issues discovered while enabling the flag, any esm external
packages will fail in client page SSR and server action. We fixed them
by changing the below bundling logics:
* When a client page having a async dependency, we can await the page
during in rendering
* When a server action having a async dependency, we changed the server
action entry creation with webpack along with the server client entry
creation together, then webpack can handle the modules async propagation
properly.
Fixes#60756
Closes NEXT-2435
Closes NEXT-2472
Closes NEXT-3225
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
For debugging purposes, it can be useful to set `NODE_ENV=development`
during a `next build`. Currently this value is forced to be production
in Next.js. This PR adds an experimental flag to not force a mode of
`production` when the flag is set.
To use this flag, you'll still need to explicitly set
`NODE_ENV=development`, while also enabling
`nextConfig.experimental.allowDevelopmentBuild`
Closes NEXT-3277
This PR promotes and renames experimental configuration options related
to server bundling:
- `serverComponentsExternalPackages` -> `serverExternalPackages`
- `bundlePagesExternals` -> `bundlePagesRouterDependencies`
Existing docs for `serverComponentsExternalPackages` was changed.
New docs for `bundlePagesRouterDependencies` were added.
Closes NEXT-3332
### What
* Extract `buildId` and server action encryption key into environment
variables for edge to make code more deterministic
* Fixed the legacy bad env names from #64108
* Always sort `routes` in prerender manifest for consistent output
* Change `environments` to `env` in middleware manifest, confirmed with
@javivelasco this is a fine change without need to bumping the version
### Why
Dynamic variants like `buildId`, SA `encryptionKey` and preview props
are different per build, which results to the non determinstic edge
bundles. Once we extracted them into env vars then the bundles become
deterministic which give us more space for optimization
Closes NEXT-3117
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
The tests added in https://github.com/vercel/next.js/pull/46219 were
never correctly testing the headers because `detectContentType()` is
called first and only when we can't detect the type from the response
body do we fallback to the `Content-Type` header.
I also refactored some of the tests because the `ctx: any` type was
causing some tests to not run when testing different configuration
options.
Closes NEXT-3321
When revalidating a page that corresponds with a dynamic path and when
using the “type” parameter, eg `revalidatePath(“/dynamic/1”, “page”)`
corresponding with `/dynamic/[id]`, the wrong cache tags would be
checked to determine if a revalidation occurred.
This is because the “derived” cache tags created for a
`/dynamic/[id]/page` are:
- /dynamic/[id]/layout
- /dynamic/[id]/page
Additionally, a tag is added for the current canonical URL, so the final
tag would be:
- /dynamic/1
Thus a fetch on `/dynamic/1` would be tagged with the following:
- /layout
- /dynamic/layout
- /dynamic/[id]/layout
- /dynamic/[id]/page
- /dynamic/1
Calling `revalidatePath(“/dynamic/1”, “page”)` would signal to
revalidate caches tagged `/dynamic/1/page` in the current logic.
However, this tag doesn’t exist given the above, so it would be a no-op
and wouldn't properly re-invoke the fetch.
This updates the docs to explicitly call out that if you are attempting
to revalidate a path that corresponds with a dynamic page, that you
should not provide a "type" argument.
Fixes#62071
Closes NEXT-3302
<!-- 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 #
-->
Hi everyone, this is my first PR to such a large project so please be
gentle. 😄 I'm also new to publishing packages so I'm not sure if I'm
missing any steps.
ESLint 9.0.0 came out a few days ago and unfortunately,
`eslint-plugin-next` is not compatible as it uses deprecated (and with
ESLint 9.0.0 removed) functions.
In this PR, I replaced the deprecated functions with the suggested
replacements ([check this
out](https://eslint.org/blog/2023/09/preparing-custom-rules-eslint-v9/)).
Regarding backwards compatibility, everything I used is available since
ESLint 8.40 (released May 2023). I'm not sure how far back Next.js
support goes but it feels fine to me.
I successfully tested some rules locally with ESLint 9.0.0 and this
`eslint.config.js` (flat config format):
```js
import js from '@eslint/js';
import nextPlugin from '@next/eslint-plugin-next';
import prettierRecommended from 'eslint-plugin-prettier/recommended';
import importSortPlugin from 'eslint-plugin-simple-import-sort';
import globals from 'globals';
import tseslint from 'typescript-eslint';
/**
* TypeScript config with strict type checking and no type checking for JS files.
*/
const typeScriptConfig = [
...tseslint.configs.strictTypeChecked,
{
plugins: {
'@typescript-eslint': tseslint.plugin,
},
languageOptions: {
parser: tseslint.parser,
parserOptions: {
project: true,
},
},
},
{
// disable type-aware linting on JS files
files: ['**/*.js', '**/*.mjs', '**/*.cjs'],
...tseslint.configs.disableTypeChecked,
},
];
/**
* Next.js config with recommended and core web vitals rules.
*/
const nextConfig = {
plugins: {
'@next/next': nextPlugin,
},
rules: {
...nextPlugin.configs.recommended.rules,
...nextPlugin.configs['core-web-vitals'].rules,
},
};
/**
* Import sort config with simple-import-sort plugin.
*/
const importSortConfig = {
plugins: {
'simple-import-sort': importSortPlugin,
},
rules: {
'simple-import-sort/imports': 'error',
'simple-import-sort/exports': 'error',
},
};
/**
* The final ESLint config wrapped with the tseslint.config helper for type hinting.
*/
export default tseslint.config(
{
ignores: ['.next', '.yarn', '**/*.d.ts', 'node_modules'],
},
{
languageOptions: {
globals: {
...globals.browser,
...globals.node,
},
},
},
js.configs.recommended,
...typeScriptConfig,
nextConfig,
prettierRecommended,
importSortConfig,
);
```
It has a few more configs but I'm sure you can remove most of them. The
important one is the `nextConfig`. Also important: Run `eslint` and not
`next lint`, it's currently not compatible with the new flat config
format.
Related discussion: https://github.com/vercel/next.js/discussions/54238
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Enabling Partial Prerendering (PPR) for an entire application is
ideally, the goal for teams wanting to test out the feature or adopt it
in their applications to get ready for when it becomes the default
rendering pattern. For large applications, with many routes the new
behaviours of old API's may prove a difficult pill to swallow all at
once.
This aims to enable incremental adoption of PPR for pages and routes
that want to support it in a similar way to how existing segment-level
configurations. Segments can now add:
```ts
export const experimental_ppr = true
```
To enable PPR for that segment and those descending segments. Any subset
of those routes that have it enabled can add:
```ts
export const experimental_ppr = false
```
<details>
<summary>An aside on the choice of <code>experimental_ppr</code>
name</summary>
<blockquote>
<p>It is against common JS semantics to use snake-case, and preference
is given to camel-case instead. The choice to make this snake-case was
to re-enforce that this is an experimental feature, an ugly incremental
path, and ideally, developers should aim to remove all references of it
from their codebase.</p>
<p>Additionally, this mirrors what we've done for unstable API's like
`unstable_cache`.</p>
</blockquote>
</details>
To disable PPR for that segment and those descending segments. To use
this new option, the `experimental.ppr` configuration in
`next.config.js` must be set to `"incremental"`:
```js
// next.config.js
module.exports = {
experimental: {
ppr: "incremental",
},
}
```
If a segment does not export a `experimental_ppr` boolean, it is
inferred from it's parent. If no parent has it defined, it's default
value is `false` and therefore disabled.
Once all your segments have PPR enabled via this config, it would be
considered safe for teams to set their `experimental.ppr` value in the
`next.config.js` to `true`, enabling it for the entire app and for all
future routes.
### Aside
I also took the liberty to rename `isPPR` and `supportsPPR` to be the
clearer `isAppPPREnabled` and `isRoutePPREnabled`.
---------
Co-authored-by: Hendrik Liebau <mail@hendrik-liebau.de>
