### What
* Move missing html tags error into error overlay, from outside we don't
have to manually determine when to render a dummy component with runtime
missing tag error or error overlay.
* Add brackets `<>` to the html tags in the error
### Why
In #62815, we're having throwing an missing required error, this will
trigger another runtime error. Then when error overlay caught it through
error event listener, it will render it as an unhandled runtime error:
You will see the below message in the overlay.
```
Unhandled Runtime Error
Error: The following tas are missing...
[Error stack]
```
This error message will bring a message that the error is happened on
client during runtime, but actually we already know that is a user side
mistake which doesn't have a error trace. This couldn't hmr as you fix
the error as well.
This PR moves the rendering into error overlay that we're aware of the
errors and can render the correct html on client, with the `html` tag
attached with error id and `body` wrapping the error overlay. We tell
overlay that there're missing tags through props, let it handle
everything inside.
It can also hmr once you fix the error. One drawback is that when you
re-introduce the error, it might trigger react DOM updates exception
(`Failed to execute 'removeChild' on 'Node': The node to be removed is
not a child of this node.`) instead of the "missing tags" message again.
Besides that the HMR works properly.
Closes NEXT-2741
This upgrades to the latest edge-runtime packages as it includes
exposing `performance`. This was reverted previously as our publishes
were failing with a specific change that has since been removed
upstream.
Closes NEXT-2730
### What?
I'm recreating a PR because CI of
https://github.com/vercel/next.js/pull/58712 uses `lightningcss@1.14.0`
for an unknown reason.
Add an opt-in feature to use `lightningcss` instead of webpack
css-loader.
### Why?
In the name of performance.
### How?
This PR is largely based on https://github.com/fz6m/lightningcss-loader
by @fz6m.
(Thank you for nice work)
Closes PACK-1998
Closes PACK-2124
---------
Co-authored-by: OJ Kwon <1210596+kwonoj@users.noreply.github.com>
### What
I noticed the font manifest generated by Turbopack was always empty.
Debugging showed that the path to the client_root was always incorrect
when calculating `get_font_paths_from_root`. And also fixed an issue
where for certain paths, the (`/index`) manifest key should contain the
original path.
Closes PACK-2666
Similar to #62611, this implements error stack translation for edge
runtime app render errors.
Test Plan: `TURBOPACK=1 pnpm test-dev
test/development/app-render-error-log/app-render-error-log.test.ts`
Closes PACK-2665
We didn't set the property of manifest before, this PR fixes the missing
prop
> If the manifest requires credentials to fetch, the crossorigin
attribute must be set to use-credentials, even if the manifest file is
in the same origin as the current page.
x-ref: https://developer.mozilla.org/en-US/docs/Web/Manifest
Fixes NEXT-2706
app dir is always "enabled", but not always exists. Rename to the proper
word to describe. Found this confusion while developing other fetaures
Closes NEXT-2691
As mentioned in the new-added error messages, and the [linked
resources](https://react.dev/reference/react/use-server#:~:text=Because%20the%20underlying%20network%20calls%20are%20always%20asynchronous%2C%20%27use%20server%27%20can%20only%20be%20used%20on%20async%20functions.):
> Because the underlying network calls are always asynchronous, 'use
server' can only be used on async functions.
> https://react.dev/reference/react/use-server
It's a requirement that only async functions are allowed to be exported
and annotated with `'use server'`. Currently, we already have compiler
check so this will already error:
```js
'use server'
export function foo () {} // missing async
```
However, since exported values can be very dynamic the compiler can't
catch all mistakes like that. We also have a runtime check for all
exports in a `'use server'` function, but it only covers `typeof value
=== 'function'`.
This PR adds a stricter check for "use server" annotated values to also
make sure they're async functions (`value.constructor.name ===
'AsyncFunction'`).
That said, there are still cases like synchronously returning a promise
to make a function "async", but it's still very different by definition.
For example:
```js
const f = async () => { throw 1; return 1 }
const g = () => { throw 1; return Promise.resolve(1) }
```
Where `g()` can be synchronously caught (`try { g() } catch {}`) but
`f()` can't even if they have the same types. If we allow `g` to be a
Server Action, this behavior is no longer always true but depending on
where it's called (server or client).
Closes#62727.
### What?
* upgrades turbopack for `getResolve` in webpack loaders
* add missing resolve-url-loader to turbopack for full sass support
Closes PACK-2634
Previously, errors shown in the error overlay, these stir were left
untraced through source maps.
Test Plan: `TURBOPACK=1 pnpm test-dev
test/development/app-render-error-log/app-render-error-log.test.ts`
Closes PACK-2608
## Description
Refactor the [Next.js
CLI](https://nextjs.org/docs/app/api-reference/next-cli) to use
[commander](https://github.com/tj/commander.js) instead of
[arg](https://github.com/vercel/arg).
## Why?
- Auto-generated, properly formatted help command + output. With `arg`,
much of the help commands were manually added via a single
`console.log`, causing deviations over time.
- Ergonomic, ease of adding new subcommands and rules
## Breaking Changes
- Update the experimental `next experimental-compile` and `next
experimental-generate` build commands in favor of `next build
--experimental-build-mode=compile/generate`
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
## What?
Working on fixing `test/e2e/conflicting-app-page-error`, this adds a
compiler error for the case where App Router routes conflict with Pages
Router routes. It's not 1:1 the same error as in webpack because in the
webpack version we hijacked the App Router resolving logic to assume
there's a certain set of paths, where Turbopack has the full route to
route tree resolving implementation which doesn't assume there's a
single page that can be resolved.
The tests are updated to reflect this change.
<!-- 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-2592
## What?
Migrates the Sass support tests from `test/integration` (legacy test
suite) to `test/e2e`, this way all these tests run against both
development and production, whereas previously most of them would only
run against production.
This is helpful as it ensures the tests are running against Turbopack
too, which is highlighting some missing features in Sass support for
Turbopack.
I've had to rewrite most of the tests to check against the actual
rendered output in the browser instead of CSS output in the `.next`
folder, the majority of these now run regardless of implementation
details.
<details>
<summary>Tests that failed with Turbopack</summary>
```
FAIL e2e/app-dir/scss/url-global-partial/url-global-partial.test.ts (84.9 s)
● SCSS Support loader handling › CSS URL via file-loader sass partial › should render the page
thrown: "Exceeded timeout of 60000 ms for a test.
Add a timeout value to this test to increase the timeout, if this is a long-running test. See https://jestjs.io/docs/api#testname-fn-timeout."
13 | })
14 |
> 15 | it('should render the page', async () => {
| ^
16 | const browser = await next.browser('/')
17 | expect(
18 | await browser.elementByCss('.red-text').getComputedCss('color')
at it (e2e/app-dir/scss/url-global-partial/url-global-partial.test.ts:15:5)
at describe (e2e/app-dir/scss/url-global-partial/url-global-partial.test.ts:7:3)
at Object.describe (e2e/app-dir/scss/url-global-partial/url-global-partial.test.ts:6:1)
FAIL e2e/app-dir/scss/composes-external/composes-external.test.ts (84.765 s)
● CSS Module Composes Usage (External) › should render the module
thrown: "Exceeded timeout of 60000 ms for a test.
Add a timeout value to this test to increase the timeout, if this is a long-running test. See https://jestjs.io/docs/api#testname-fn-timeout."
12 | })
13 |
> 14 | it('should render the module', async () => {
| ^
15 | const browser = await next.browser('/')
16 | expect(
17 | await browser.elementByCss('#verify-yellow').getComputedCss('color')
at it (e2e/app-dir/scss/composes-external/composes-external.test.ts:14:3)
at Object.describe (e2e/app-dir/scss/composes-external/composes-external.test.ts:6:1)
FAIL e2e/app-dir/scss/composes-basic/composes-basic.test.ts (35.629 s)
● CSS Module Composes Usage (Basic) › should render the module
expect(received).toBe(expected) // Object.is equality
Expected: "rgb(255, 255, 0)"
Received: "rgb(0, 0, 0)"
16 | expect(
17 | await browser.elementByCss('#verify-yellow').getComputedCss('color')
> 18 | ).toBe(colorToRgb('yellow'))
| ^
19 | expect(
20 | await browser
21 | .elementByCss('#verify-yellow')
at Object.toBe (e2e/app-dir/scss/composes-basic/composes-basic.test.ts:18:7)
FAIL e2e/app-dir/scss/npm-import-nested/npm-import-nested.test.ts (90.889 s)
● Good Nested CSS Import from node_modules › should render the page
thrown: "Exceeded timeout of 60000 ms for a test.
Add a timeout value to this test to increase the timeout, if this is a long-running test. See https://jestjs.io/docs/api#testname-fn-timeout."
12 | })
13 |
> 14 | it('should render the page', async () => {
| ^
15 | const browser = await next.browser('/')
16 | expect(
17 | await browser.elementByCss('.red-text').getComputedCss('color')
at it (e2e/app-dir/scss/npm-import-nested/npm-import-nested.test.ts:14:3)
at Object.describe (e2e/app-dir/scss/npm-import-nested/npm-import-nested.test.ts:6:1)
FAIL e2e/app-dir/scss/nm-module-nested/nm-module-nested.test.ts (81.941 s)
● Valid Nested CSS Module Usage from within node_modules › should render the page
thrown: "Exceeded timeout of 60000 ms for a test.
Add a timeout value to this test to increase the timeout, if this is a long-running test. See https://jestjs.io/docs/api#testname-fn-timeout."
12 | })
13 |
> 14 | it('should render the page', async () => {
| ^
15 | const browser = await next.browser('/')
16 | expect(await browser.elementByCss('#other2').getComputedCss('color')).toBe(
17 | colorToRgb('red')
at it (e2e/app-dir/scss/nm-module-nested/nm-module-nested.test.ts:14:3)
at Object.describe (e2e/app-dir/scss/nm-module-nested/nm-module-nested.test.ts:6:1)
```
</details>
<!-- 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-2550
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
### What
Keep improving the hydration erros. Currently we divide the hydration
mismatch types into two categories, html tag mismatch and text mismatch.
We're displaying the mismatched text content between server and client
here since we have it in the component stack and warnings.
We've already made some improvements in #62590 , here we carry on
improving the highlited text into red and bold that is much easier for
you to spot on.
This updated a few long snapshots that we could collapse and show only
the text content difference instead of all the component stack.
### Screenshots
(Dark and light modes)
#### Mismatch html tags
<img width="360"
src="https://github.com/vercel/next.js/assets/4800338/f721b374-69cc-4600-a09d-bef87e885fab"><img
width="360"
src="https://github.com/vercel/next.js/assets/4800338/1abf2572-2be8-4359-a652-8ba39aaccfd3">
#### Mismatch text content
<img width="360"
src="https://github.com/vercel/next.js/assets/4800338/7f0d2215-8bc0-4fba-9c92-6c44efa29531"><img
width="360"
src="https://github.com/vercel/next.js/assets/4800338/656d1e1a-3157-4bcf-a239-74bb81fcb4c4">
#### Large content mismatch
### Why
I was intended to bring a html diff between server and client html
content but turns out the diff result could be giant and not ideal due
to few reasons. So we switched to the path of leveraging component stack
and mismatch contents.
React reordering the tags after hydration. For instance the `script` or
`link` tags could be hoist by React Float, so the lines of html is are
to preserved. so the diff is hard to be super accurate unless your
mismatch is small. If you're mismatch a component with rich html
content, it could be a pretty large diff.
Another case is if you have a bad nesting html like `<p> ...<span>...
<p>my text</p> ...</span>... <p>` where there're many span in between,
the final different could also be hudge as browser will close the first
`<p>` tag and the rest content will go into the diff. Hence we're going
with the component and text content diff.
Closes NEXT-2645
### What?
We now keep track of all client assets emitted for each route in
`ClientAssetMapper` and remove all issues associated with them when a
route get deleted.
Fixes#61384
Closes PACK-2487
## 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
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?
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
