This test was failing with my changes in
https://github.com/vercel/next.js/pull/64932 because it was using the
new Next.js changes, but not the corresponding react-dom changes.
An alternative solution would be to update the react-dom versions to
match those in the rest of the project (19 beta), but I think this is
better overall.
After removing the dependencies, this test works in my branch.
## What
Ensures `nonce` is added to script and link tags Next.js renders.
Additional cases it now handles:
- We already passed `nonce` to the React rendering, though not
consistently on all cases where `renderToStream` is called, I'm
surprised there haven't been more reports of this, but now it will pass
it on all cases where React rendering is called that I could find
- In `get-layer-assets.tsx` we now pass `nonce` to both the `script` and
`link` tags
- When calling `ReactDOM.preload` the nonce was missing as well, ensured
that the nonce is included in that case as well.
Added a test that mimicks the reproduction by adding `next/font` in this
case.
Fixes#64037
Closes PACK-2973
<!-- 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 #
-->
Explain more details about default `metadataBase` (where `metadataBase`
is not defined) when it's on Vercel deployment
x-ref: https://github.com/vercel/next.js/pull/65089
---------
Co-authored-by: Delba de Oliveira <32464864+delbaoliveira@users.noreply.github.com>
We've seen too many instances of folks accidentally committing their
`.env` files that I feel it's time to make this change.
Up until now, Next.js has recommended that you use `.env.local` when
working locally to store your environment variables. Some developers do
intentionally want to commit their `.env` file without secret values to
source control. However, the ecosystem is fragmented on `.local`
support.
There are tools which require secrets values that do _not_ support
`.local` and require using `.env`. This means that it's possible to dump
your secret values into a `.env` file and commit to source control,
thinking that the defaults would have you covered.
This change updates the defaults for `create-next-app` to ignore all
`.env` files by default. If you want to commit then, you opt-in by
modifying your `.gitignore`, versus the opposite.
Related: https://x.com/complexlity/status/1755890800527892716
---------
Co-authored-by: Sam Ko <sam@vercel.com>
## Why?
Adding an `--empty` flag so we can easily create an empty Create Next
App template.
Closes NEXT-3367
---------
Co-authored-by: Ahmed Abdelbaset <A7med3bdulBaset@gmail.com>
### What
Remove the extra `__esModule` and `$$typeof` export for ESM client
module
For a client page reference, it changed on server side in renderer:
Previous: `{ __esModule, $$typeof, default }`
Now: `{ default }`
### Why
The Module object itself appears as a client reference but it can't be
rendered since it's not a real reference. I'm not sure why it was added
but I think the right thing for an ESM module is to not treat the module
itself as a client reference but only the objects inside of it. E.g. the
"default" export. That's what React does upstream for ESM modules.
Closes NEXT-3360
Noticed while doing some testing that this route was broken in this
application. We use some parts of this app to generate statistics - I'm
planning to use more of the routes for benchmarking so I wanted to
ensure it was working.
Closes NEXT-3371
### What
Remove the auto appending `.xml` extension to the sitemap routes when
it's a dynamic route.
### Why
Previously we were adding `.xml` to `/[...paths/]sitemap` routes, but
the bad part is when you use it to generate multiple sitemaps with
`generateSitemaps` in format like `/[...paths/]sitemap.xml/[id]`, which
doesn't look good in url format and it can be inferred as xml with
content-type. Hence we don't need to add `.xml` in the url.
Before this change it could also result into the different url between
dev and prod:
dev: `/sitemap.xml/[id]`
prod: `/sitemap/[id].xml`
Now it's going to be aligned as `/sitemap/[id]`. Users can add extension
flexiblely.
Closes NEXT-3357
This test failed in dev. It has 2 problems:
1. the nanoid only contains named export
2. we should wait for the content changed then check the browser url
```
● app-dir action handling › fetch actions › should handle redirects to routes that provide an
invalid RSC response
expect(received).toBe(expected) // Object.is equality
Expected: "http://localhost:50473/pages-dir"
Received: "http://localhost:50473/client"
891 |
892 | await retry(async () => {
> 893 | expect(await browser.url()).toBe(`${next.url}/pages-dir`)
```
Closes NEXT-3369
Reverts vercel/next.js#65321
Missed covering `api` layer, got reported with below error. Revert it
for now and will re-land it with more tests
```
../../node_modules/.pnpm/next@14.3.0-canary.51_@opentelemetry+api@1.7.0_react-dom@18.2.0_react@18.2.0/node_modules/next/dist/client/components/navigation.js
02:23:13
Module not found: shared-runtime module app-router-context cannot be used in api layer
02:23:13
https://nextjs.org/docs/messages/module-not-found
```
### 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>
