## What?
#62528 caused test/e2e/app-dir/not-found/conflict-route to fail
compilation in Turbopack, this compiler error was previously already
reported by Turbopack but Next.js didn't show it, which #62528 resolved.
This PR changes the handling for the not-found handling to be consistent
between development and build, which ensures that the "special" page no
longer conflicts with app/not-found/page.js.
Closes NEXT-2617
Note: this is a reworked iteration of
https://github.com/vercel/next.js/pull/62585 which wasn't sufficient.
<!-- 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 #
-->
### What?
Do not fail when `useSelectedLayoutSegment` or
`useSelectedLayoutSegments` APIs are called in the Pages Router.
### Why?
This makes migration easier and creates consistency with our other App
Router-specific APIs that inherit the same behavior.
### How?
Similar to #47490, we return `null` if there is no Layout context
(indicating being in Pages Router)
Types are also overridden in the navigation compact module declaration
which kicks in during start to correct the types if we detect a `pages/`
directory.
Note to reviewer: #47490 didn't add a test, so I added one top-level,
let me know if you have a better suggestion for placing.
Closes NEXT-2506
Fixes#61464
### What?
Fixes https://github.com/vercel/next.js/issues/62525
Closes NEXT-2620
Since codes below do not consider searchParams, `redirect` in server
action removes all searchParams passed from client side.
93e4bb823c (diff-c809d50461027cdba7c092e564818b1172133d337abc5c513f829c94c8483dc6R186)
So I just add conditional branch for searchParams.
---
lint, prettier was applied.
Also I have done tests by commands below. and it was all passed.
```
pnpm testonly --testPathPattern "integration" -t "redirect"
```
---------
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
### What
This PR enables lightningcss features in next-swc. Currently this is for
the native build targets only, for the wasm there are some unknown build
error prevents to enable this.
Closes PACK-2607
### What
When you have bad nesting html in your React code, React wil raise
hydration error since the browser html parser might parse it to sth else
different comparing to server html on client. Previously we're display
only the warning in the error description in dev overlay.
Now we introduced another format of displaying pesudo html that
representing your code, with highlighting the html tag that causes the
error. Since React might gives you the whole component stack of React
tree, so we also introduced a way that can collapse the error.
#### Example
https://github.com/vercel/next.js/assets/4800338/622122d6-4d2e-4c8e-95e8-4864343e478b
### Why
The reason we added this is that even we show the html diff, it could
super large due to React ordering the html on client, so the mismatch
might be a lot. The idea here is similar to what you saw when you passed
down a bad event handler into server component, we displayed a pesudo
html as it could hit your mind faster than just seeing the warning. The
best way is to display the source code, but before we can show the
source, getting component stack display as pseudo html instead of here
could be more helpful.
### After vs Before
<img width="400"
src="https://github.com/vercel/next.js/assets/4800338/714119ad-ff23-46a9-bc5a-5601eb390e71">
<img width="400"
src="https://github.com/vercel/next.js/assets/4800338/575f95fa-889e-4cee-ad19-9c2fea06519a">
Closes NEXT-2621
### Problem
We've identified a bug within Next.js's pages router when utilizing the
shallow routing API, specifically when invoking `router.push` with the
`{ shallow: true }` option, like so:
```javascript
router.push('/?counter=10', undefined, { shallow: true });
```
Shallow routing is designed to update the URL without running data
fetching methods such as getServerSideProps, getStaticProps, or
getInitialProps. However, a side effect of this process is that it skips
the clean-up of the cancelHandler. This leads to router error events
being fired erroneously, causing confusion and potential stability
issues, as the system behaves as if an error occurred when, in fact,
none did.
### Solution
This PR addresses the issue by modifying the shallow routing logic to
also skip the creation of the cancelHandler. Given that shallow routing
operations are synchronous and do not involve data fetching or other
asynchronous tasks that might need to be canceled, the cancelHandler is
unnecessary in this context.
fixes#61772
---------
Co-authored-by: Shu Ding <g@shud.in>
## What?
Currently flight-manifest-plugin relies on looping over all webpack
chunk groups and trying to infer the entrypoint name from them, which
can be brittle in cases where the chunk group doesn't match exactly with
the entrypoint, which happens for the `_not-found` entrypoint for
example.
This PR changes the implementation to use `compilation.entrypoints`
directly. `compilation.entrypoints` is a `Map` where the key is the
entrypoint name and the value is the entrypoint chunk group, exactly
what this logic was looking for in the current implementation.
<!-- 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 #
-->
Closes NEXT-2637
### What?
generateSitemaps function returns a 404 for /sitemap/[id].xml in
production
### Why?
While finding the correct sitemap partition from the array, we check the
param against the id. Which works in dev because id and param are both
without trailing .xml. But it fails in production as param has a
trailing .xml (/sitemap/[id] works in production because it falls back
to dynamic loading and param and id are both without .xml)
### How?
If we are in production environment, check the id with a trailing .xml
because that's whats returned from generateStaticParams, an array of
__metadata_id__ with trailing .xml
Fixes#61969
---------
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
This moves the locale redirect handling out of `base-server` as it
shouldn't be handled here and should be at the routing level. This
avoids the duplicate handling with middleware that causes the incorrect
detection/infinite looping. Test case from separate PR was carried over
to prevent regression.
Fixes: https://github.com/vercel/next.js/issues/55648
Closes: https://github.com/vercel/next.js/pull/62435
Closes: NEXT-2627
Closes: NEXT-2628
---------
Co-authored-by: Nourman Hajar <nourmanhajar@gmail.com>
Co-authored-by: samcx <sam@vercel.com>
### What
Change from processing the file with `next-metatdata-route-loader`
directly into passing the file as loader query, and leave an empty
resource file for it. This will resolve the error that users were seeing
with `manifest.json` convention.
```
Import trace for requested module:
../../../../packages/next/dist/build/webpack/loaders/next-metadata-route-loader.js?page=%2Fmanifest.jso
n%2Froute&isDynamic=0!./app/manifest.json?__next_metadata_route__
getStaticAssetRouteCode page /manifest.json/route this.resourcePath /Users/huozhi/workspace/next.js/tes
t/e2e/app-dir/metadata-json-manifest/app/manifest.json
```
### Why
I looked at the loader process that the final resource processed by
webpack is `json!next-metadata-route-loader...`, which means the builtin
json loader processing json file after the metadata route loader. I
didn't get chance to solve the ordering issue, so I changed the
resourcePath to empty "", and pass the file path as query into the
loader to avoid json-loader processing it after transpilation.
Fixes#59923
Closes NEXT-2630
Closes NEXT-2439
This ensures our dynamic routes that have the same specificity as
`_next/static/:path*` don't get matched unexpectedly when the
`_next/static` asset doesn't exist. We were holding off on making this
change explicit due to compatibility concerns but these are no longer a
concern and the unexpected matching is more of a concern.
Closes: CSM-11
Fixes: https://github.com/vercel/next.js/issues/19270
Closes NEXT-2613
### What
Fixes `redirect()` call under suspense boundary, redirect url should
include the `basePath` in the url.
### Why
`redirect()` under suspense boundaries will go through server html
insertion, which is being used every time by suspense boundary resolved,
new errors will triggered from SSR streaming. It was missing before.
Fixes NEXT-2615
Fixes#62407
### What?
We should treat the warning for CSR bailout the same as the hard-error,
and show the stack trace for either case.
### Why?
It might be useful to track down the source of this warning.
### How?
We have the stack info already, but we only showed it during the error
logging. We should show it for warnings too.
This is similar to #61200
Closes NEXT-2624
Addresses #57066
Currently, a user running `next start` on an un-built Next.js project
receives a confusing uncaught error before the process just ends:
```
▲ Next.js 14.1.0
- Local: http://localhost:3000
[Error: ENOENT: no such file or directory, open '/home/flotwig/src/project/.next/BUILD_ID'] {
errno: -2,
code: 'ENOENT',
syscall: 'open',
path: '/home/flotwig/src/project/.next/BUILD_ID'
}
```
In my case, I ran into this because I had not worked with Next.js for a
while, and I forgot that `next dev` was used for local development, not
`next start`. I believe many of the confused users in #57066 are making
a similar mistake and not realizing it, due to the error message.
This PR catches an `ENOENT` when reading `BUILD_ID` and suggests that
the user `next build` or `next dev` to remove this friction point:
```
▲ Next.js 14.1.1-canary.69
- Local: http://localhost:3000
Error: Could not find a production build in the '.next' directory. Try building your app with 'next build' before starting the production server. https://nextjs.org/docs/messages/production-start-no-build-id
at setupFsCheck (/home/flotwig/src/next.js/packages/next/src/server/lib/router-utils/filesystem.ts:157:13)
at initialize (/home/flotwig/src/next.js/packages/next/src/server/lib/router-server.ts:90:21)
at Server.<anonymous> (/home/flotwig/src/next.js/packages/next/src/server/lib/start-server.ts:295:28)
```
A few things probably need to be resolved before this PR can merge, I
would appreciate any input from Next.js maintainers.
- [x] Is this the best place to catch this? I am not familiar with the
Next.js codebase, so I just caught this in the most obvious way.
- [x] Can the error message be improved?
- [x] Add a test for the error in `test/development`
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What
When the popstate action is fired (as is the case in a browser back
button), if the page you're going back to has missing cache node data,
the router will crash.
### Why
Almost all router actions will suspend at the app-router level with the
exception of `ACTION_RESTORE`. This was to address an issue where
suspending in the router would add enough delay for browser scroll
restoration behavior not to work.
As a result, when going back to the page with missing data, app-router
wouldn't suspend but layout-router would suspend on the missing data
while triggering a lazy fetch. We trigger a server-patch with the
applied lazy data, but when React replays the render, it will replay the
branch without the cache node data applied. This results in the router
getting caught in a loop of suspending, applying the cache node,
replaying the branch without the cache node, and eventually crashing due
to an error thrown by React to prevent re-suspending indefinitely.
### How
This adds a property to the cache node to signal if the lazy data has
been resolved. If it has been, we won't call the server patch action
again.
Fixes#61336
Closes NEXT-2438
Currently to redirect to another RSC route of the same app, we initiate
another request to that route. This PR changes that request to directly
use the internal hostname of the current server handler, rather than
relying on other headers.
Closes NEXT-2614
### What
Introduce a `react-server` export condition of `next/navigation`, which
only take effects in RSC layer. And it will only contain `notFound` and
`redirect` related APIs, which can be shared in both server components
and client components environment. This export excludes those APIs
working with React context which are only working in client components.
### Why
We fixed an issue bad alias for react-server condition of react itself
in
https://github.com/vercel/next.js/pull/61522/files#diff-ecb951c8d26893f6d1e4425a873b399d52346ef63eb90fba79d980cef2fabe8cL35
, this was a good fix. But we found that if you're using edge runtime
with `next/navigation` it will error with bundling that you're attempted
to import some client component hooks such as `useContext` from react.
So we introduced a `react-server` version of `next/navigation` that
doesn't interoplate with any client hooks, can we'll bundle that one
instead of original `next/navigation` when you're using it in server
components or app routes.
Closes NEXT-2583
Closes NEXT-2519
Fixes#62187
### What?
Hide frames that start with `node:internal`.
### Why?
These are usually unactionable anyway.
### How?
Filter these lines the same way we filtered `stringify <anonymous>` in
#62325
Closes NEXT-2593
### What?
Reduces the number of css chunks per entrypoint by merging chunks.
### Why?
In larger application the total CSS deduplication approach falls short
in a sense of it's causing way too many separate chunks, which results
in way to many requests. That affects page load performance.
Closes PACK-2598
With Server Actions, a module-level encryption can happen when you do:
```js
function wrapAction(value) {
return async function () {
'use server'
console.log(value)
}
}
const action = wrapAction('some-module-level-encryption-value')
```
...as that action will be created when requiring this module, and it
contains an encrypted argument from its closure (`value`). This
currently throws an error during build:
```
Error: Missing manifest for Server Actions. This is a bug in Next.js
at d (/Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/chunks/1772.js:1:15202)
at f (/Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/chunks/1772.js:1:16917)
at 714 (/Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/app/encryption/page.js:1:2806)
at t (/Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/webpack-runtime.js:1:127)
at 7940 (/Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/app/encryption/page.js:1:941)
at t (/Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/webpack-runtime.js:1:127)
at r (/Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/app/encryption/page.js:1:4529)
at /Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/app/encryption/page.js:1:4572
at t.X (/Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/webpack-runtime.js:1:1181)
at /Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/app/encryption/page.js:1:4542
```
Because during module require phase, the encryption logic can't run as
it doesn't have Server/Client references available yet (which are set
during the rendering phase).
Since both references are global singletons to the server and are
already loaded early, this fix makes sure that they're registered via
`setReferenceManifestsSingleton` before requiring the module.
Closes NEXT-2579
