### Why
We calculate the “next url” depending on the router state and the previous router state so that when you navigate to a route, the proxy matches with that header and returns you the intercepted route if matching
### What
- Fixes#52745
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
This breaks out routing handling from `next-server`, `next-dev-server`,
and `base-server` so that these are only handling the "render" work and
eventually these will be deleted completely in favor of the bundling
work being done.
The `router` process and separate `render` processes are still
maintained here although will be investigated further in follow-up to
see if we can reduce the need for these.
We are also changing the `require-cache` IPC to a single call instead of
call per entry to reduce overhead and also de-dupes handling for
starting the server between the standalone server and normal server.
To maintain support for existing turbopack route resolving this
implements the new route resolving in place of the existing
`route-resolver` until the new nextturbo API is fully landed.
After these initial changes we should continue to eliminate non-render
related code from `next-server`, `base-server`, and `next-dev-server`.
This PR tries to address some feedback around prefetching, like in #49607, where they were some warnings because we were over prefetching.
The tweaks in this PR:
- if there are no loading boundary below, we don't prefetch the full page anymore. I made that change a while ago but I think it wasn't the original intent from @sebmarkbage. Fixing that now. So now, we will prefetch the page content until the nearest loading boundary, only if there is any.
- there's now a queue for limiting the number of concurrent prefetches. This is to not ruin the bandwidth for complex pages. Thanks @alvarlagerlof for that one.
- also, if the prefetch is in the queue when navigating, it will get bumped.
- bonus: fixes a bug where we were wrongly stripping headers in dev for static pages
Test plan:
<img width="976" alt="CleanShot 2023-07-20 at 17 53 43@2x" src="https://github.com/vercel/next.js/assets/11064311/2ea34419-c002-4aea-94df-57576e3ecb2e">
In the screenshot you can see that:
- only 5 requests at a time are authorised
- when I clicked on 15, it got prioritised in the queue (did not cancel the rest)
- the prefetch only included the content until the loading boundary
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
### What
This PR changes the flow of not-found rendering process.
### Why
`not-found.js` was rendered in two ways before:
* 1 is SSR rendering the not-found as 404
* 2 is triggering the error on RSC rendering then the error will be
preserved in inline flight data, on the client it will recover the error
and trigger the proper error boundary.
The solution has been through a jounery:
No top-level not found boundary -> introduce metadata API -> then we
create a top level root not found boundary -> then we delete it due to
duplicated rendering of root layout -> now this
So the solution before this PR is still having a root not found boundary
wrapped in the `AppRouter`, it's being used in a lot of places including
HMR. As we discovered it's doing duplicated rendering of root layout,
then we removed it and it started failing with rendering `not-found` but
missing root layout. In this PR we redesign the process.
### How
Now the rendering architecture looks like:
* For normal root not-found and certain level of not-found boundary
they're still covered by `LayoutRouter`
* For other error renderings including not-found
* Fully remove the top level not-found boundary, when it renders with
404 error it goes to render the fallback page
* During rendering the fallback page it will check if it should just
renders a 404 error page or render nothing and let the error from inline
flight data to trigger the error boundary
pseudo code
```
try {
render AppRouter > PageComponent
} catch (err) {
create ErrorComponent by determine err
render AppRouter > ErrorComponent
}
```
In this way if the error is thrown from top-level like the page itself
or even from metadata, we can still catch them and render the proper
error page based on the error type.
The problematic is the HMR: introduces a new development mode meta tag
`<meta name="next-error">` to indicate it's 404 so that we don't do
refresh. This reverts the change brougt in #51637 as it will also has
the duplicated rendering problem for root layout if it's included in the
top level not found boundary.
Also fixes the root layout missing issue:
Fixes#52718Fixes#52739
---------
Co-authored-by: Shu Ding <g@shud.in>
We have the logic to group the client compiler's entry names to make sure we generate one single manifest file for the page. This is complicated and requires a special step to "group" the entry names because a page can depend on a bunch of files from everywhere.
And currently, the normalization of "entryName → groupName" doesn't cover interception routes' conventions (`(.)`, `(..)` and `(...)`). This PR fixes that.
Closes#52862, closes#52681, closes#52958.
### What?
- Visiting a page in the app router without a proper component export doesn't show the dev overlay, but logs errors to the console
- When it does show the error overlay (e.g. during an HMR event), the error message was sharing the module code itself rather than the component path, making it hard to debug
### Why?
`createComponentTree` can throw these errors before the AppRouter tree is mounted, leaving the errors uncaught by the dev overlay.
### How?
This wraps the server root in the `ReactDevOverlay` when in dev mode with a minimal "HMR" for when the server component is edited (to reload the page).
Closes NEXT-308
This updates our `moduleResolution` to `bundler` as this matches our heuristics much more closely so is more accurate. This shouldn't be a breaking change is it should be compatible with our previous default.
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
When doing dynamic imports like `import(variable)`, Webpack _tries_ to statically analyze it and creates a regex like context module for it (which includes all possible modules). This `ContextModule` doesn't have a resource path so we need to use the identifier to track it.
Tested with @alexkirsz's repro here https://github.com/vercel/next.js/issues/50243#issuecomment-1628675346 and confirmed that it fixes the problem.
Closes#50243.
This ensures we properly detect `not-found` as `runtime = 'edge'` and treat it as such instead of attempting to render it like normal.
x-ref: https://github.com/vercel/next.js/issues/52648
### What?
Support metadata exports for `not-found.js` conventions
### Why?
We want to define metadata such as title or description basic properties for error pages, including 404 and 500 which referrs to `error.js` and `not-found.js` convention. See more requests in #45620
Did some research around metadata support for not-found and error convention. It's possible to support in `not-found.js` when it's server components as currently metadata is only available but for `error.js` it has to be client components for now so it's hard to support it for now as it's a boundary.
### How?
We determine the convention if we're going to render is page or `not-found` boundary then we traverse the loader tree based on the convention type. One special case is for redirection the temporary metadata is not generated yet, we leave it as default now.
Fixes#52636
### What
This was an issue introduced in #52416 when we check the images and icons property while merging with static file conventions. Where we should check if the properties are present but we only checked if they value is falsy. So when you're using `icons` with array value it breaks.
Now we properly check all the possible case of `metadata.icons` value, so then decide if we are using the static file convention or the icons property of defined metadata.
Also add few more tests cases to cover icons resolving.
References for Client Components need to be aggregated to the page entry level, and emitted as files in the correct directory for the SSR server to read from. For normal routes (e.g. `app/foo/bar/page`), we can go through and collect all entries (layout, loading, error, ...) from the current and parent segments, to aggregate all necessary client references.
However, for routes with special conventions like `app/(group)/@named/foo/bar/page`, it needs to be normalized (remove the named slot and group segments) so it can be grouped together with `app/(group)/@named2/foo/bar/loading`.
When there's a runtime error showing in root layout (server components), it should be able to catch by `global-error`.
For server components, we caught it and gonna render the error fallback components (either not-found or error page), and the response status is `200`, and since we'll display error dev overlay in developmenet mode so we only render `global-error` for production.
So that you can catch more errors with `global-error` and maybe do potential error tracking on client side.
Follow up of #52573
Closes NEXT-1442
minor refactor: move `appUsingSizeAdjust` into `Metadata` component so that we can just tune the flag as prop
We have some special bundle path handling logic for `/index` routes in
`normalizePagePath`, which is missing in the new
`AppBundlePathNormalizer`. This already broke `/index/page.js` in dev in
the past, and now become noticeable in prod as well because of the
manifest change.
b98469c86b/packages/next/src/shared/lib/page-path/normalize-page-path.ts (L5-L14)
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Introduce a new way to search for `not-found` component that based on
the request pathname and current loader tree of that route. And we
search the proper not-found in the finall catch closure of app
rendering, so that we don't have to pass down the root layout to
app-router to create the extra error boundary.
This ensures the root layout doesn't have duplicated rendering for
normal requests
Fixes NEXT-1220
Fixes#49115
Transitions the App Pages renderer into the entrypoint bundle.
- Adjusts the static path detection to handle route module's with App Pages
- Fixes bug in font manifest loading on Edge
This PR ensures that both Webpack and the config won't be initiated in render workers. This is great for performance but also avoids potential issues (e.g. Next.js plugin with side effects). Instead, we pass a serialized config from the router worker to the render workers.
Closes#52366.
Previously `global-error` only caught the error on client side, this PR adds the support for catching the errors thrown during client components SSR or server components RSC rendering.
Closes#46572Closes#50119Closes#50723
The problem was introduced in #52450, that the client reference manifest isn't being tracked and included in the function.
Verified that this fixes the issue.
This PR changes client manifest generation process. Instead of one big
manifest file that contains client references for the entire app, we're
now generating one manifest file per entry which only covers client
components that can be reached in the module graph.
Metadata API should provide a way to override the filebased metadata
images. As usually for child routes, if there's new social images or
icons are provided, the ones from parent routes should be overridden /
skipped.
The `metadata` object export or `generateMetadata` should be able to do
that. Sometimes users still add other og info (besides images) to
metadata export (both object and `generateMetadata`).
I think we should check if they really have returned images property,
then decide to override.
- For the same level of routes:
- If there's no `openGraph.images` in the returned value, merge with
file based images
- If there's any `openGraph.images` in the returned value, ignore file
based ones
- For child level of routes:
Always override the parent level, ignoring parent level file based
images unless they use `generateMetadata` to merge from
`resolvingParentMetadata` value, then the parent level's file based ones
will present there
Closes NEXT-1418
After we separating the metadata routes to a separate layer, we didn't apply the webpack alias rules properly to it as it's should still be treated as pure "server" side
This PR fixes the aliasing for that new metadata layer and make it working properly with "server-only"
Fixes#52390
This reverts the change to the pages render until a more substantial refactor can ensure that using the custom `app.render` method will attach a match to the request metadata.
- Fixes#52384
### What?
HMR causes infinite reloads for parallel routes when the corresponding page component is nested
### Why?
In 4900fa21b078fd1ec1adc5d570fcfb560be8aeb6, code was added to remove `/@children` from the page path (if present) but in 59b36349eb86427ac7b679ac62fa6628c9fc4886, `normalizeParallelKey` removes the @ prefix from children, so this doesn't seem to be catching the scenario it was intended to prevent
### How?
This updates the existing replace logic to consider `/children/page` rather than `/@children/page` -- it doesn't seem like `/@children` is a valid scenario given the `normalizeParallelKey` behavior
Fixes#52342 and addresses the concerns in https://github.com/vercel/next.js/pull/52061#issuecomment-1619145129
Adds a regression test for testing progressive enhancement of Server
Actions. Both when passed from a Server Component and when imported into
a Client Component.
#51723 landed a bit too early which broke this but it'll be fixed again
once React is upgraded.
Co-authored-by: Shu Ding <g@shud.in>
### Issue
x-ref:
https://github.com/vercel/next.js/actions/runs/5469070005/jobs/9957658991?pr=52282#step:27:526
metadata tests are failing as flaky recently, then after digging into
it, noticed it as a hmr issue.
**Steps to repro with metadata test app**
The later (after the 1st one) visited page with client components
imports sometimes throw an full reload refresh warning
> Fast Refresh will perform a full reload when you edit a file that's
imported by modules
outside of the React rendering tree.
Turns out there's some unexpected hmr events when `"sync"` event is
triggered, and client tries to apply the updates but then failed. This
PR excludes the triggering by `"sync"` for RSC pages updates. `'sync'`
event with errors/warnings will still be handled and then `'built'`
event will be handled with hot reload updates
Possibly related to #40184
### What?
I've found 2 more spots that didn't properly cancel the streaming response when the client disconnects. This fixes `RenderResult.pipe()` (called during dynamic render results) and `sendResponse()` (used during Route Handlers using `nodejs` runtime).
It also (finally) adds tests for all the cases I'm aware of.
### Why?
To allow disconnecting from an AI service when a client disconnects. $$$
### How?
Just checks for `response.closed`, which will be closed when the client's connection disconnects.
### Issue
When the og module is a shared module being imported in both page and metadata image routes, it will be shared in the module graph. Especially in the edge runtime, since the `default` export is being used in the metadata image routes, then it can't be easily tree-shaked out.
### Solution
Separate the image route to a separate layer which won't share modules with the page, so that image route is always bundling separately and the `@vercel/og` module only stays inside in that layer, when import image metadata named exports (size / alt / etc..) it can be still tree shaked.
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
### What?
When there's a parallel route adjacent to a tree that has no page
component, it's treated as an invalid entry in `handleAppPing` during
dev HMR, which causes an infinite refresh cycle
### Why?
In #51413, an update was made to `next-app-loader` to support layout
files in parallel routes. Part of this change updated the parallel
segment matching logic to mark the parallel page entry as `[
'@parallel', [ 'page$' ] ]` rather than `[ '@parallel', 'page$' ]`.
This resulted in `handleAppPing` looking for the corresponding page
entry at `client@app@/@parallel/page$/page` (note the `PAGE_SEGMENT`
marker) rather than `client@app@/@parallel/page`, causing the path to be
marked invalid on HMR pings, and triggering an endless fastRefresh.
### How?
A simple patch to fix this would fix this is to update `getEntryKey` to
replace any `PAGE_SEGMENT`'s that leak into the entry which I did in
59a972f53339cf6e444e3bf5be45bf115a24c31a.
The other option that's currently implemented here is to only insert
PAGE_SEGMENT as an array in the scenario where there isn't a page
adjacent to the parallel segment. This is to ensure that the
`parallelKey` is `children` rather than the `@parallel` slot when in
[`createSubtreePropsFromSegmentPath`](59a972f533/packages/next/src/build/webpack/loaders/next-app-loader.ts (L298)).
This seems to not cause any regressions with the issue being fixed in
51413, and also solves this case, but I'm just not 100% sure if this
might break another scenario that I'm not thinking of.
Closes NEXT-1337
Fixes#51951
### What
Support `scroll={false}` for Link component in app router. This can be
used when you don't need to scroll back to top again when route url
changes. For instance hash query changes, if you want to keep the
scrolling as it is, you can use this option.
### How
Handling the `scroll` option in navigation reducer on client side.
Fixes#50105
Fixes NEXT-1377
---------
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
Currently we are validating the `experimental.serverActions` flag when creating the actual entries for Server Actions, this causes two problems. One is that syntax errors caught at compilation time are still shown, even if you don't have this flag enabled. Another problem is we still traverse the client graph to collect these action modules even if the flag isn't enabled.
This PR moves that check to be happening at compilation time, which addresses the two above but also brings the extra benefit of showing the exact span and module trace that errors:
<img width="974" alt="CleanShot 2023-07-03 at 20 26 34@2x" src="https://github.com/vercel/next.js/assets/3676859/1676b1f6-e205-4963-bce4-5b515a698e9c">
This adapts the new route module rendering to support edge as well.
- Added a new `routeModule` export to the Edge SSR Loader
- Updated some tests to validate page state
Fixes NEXT-1327
When looking at [some sites](https://rsc-llm-on-the-edge.vercel.app/) with a large amount of chunks streamed, I noticed that the inlined Flight data array can be optimized quite a lot. Currently we do:
```js
self.__next_f.push([1,"d5:[\"4\",[\"$\",\"$a\",null,..."])
```
1. The `self.` isn't needed (except for the initial bootstrap tag) as React itself has `<script>$RC("B:f","S:f")</script>` too.
2. After the bootstrap script tag, all items are an array with `[1, flight_data]` and `flight_data` is always a string. We can just push only these strings.
3. We use `JSON.stringify(flight_payload)` to inline the payload where the payload itself is a string with a lot of double quotes (`"`), this results in a huge amount of backslashes (`\`). Here we can instead replace it to use a pair of single quotes on the outside and un-escape the double quotes inside.
Here's a side-by-side comparison of a small page:
<img width="1710" alt="CleanShot 2023-06-30 at 11 41 02@2x" src="https://github.com/vercel/next.js/assets/3676859/398356ec-91d5-435c-892d-16fb996029e8">
For a real production page I saw the HTML payload reduced by 11,031 bytes, a 3% improvement.
Note that all the tests are not considering gzip here, so the actual traffic impact will be smaller.
We show the "Application error: a client-side exception has occurred (see the browser console for more information)" error incorrectly when a server-side error occurs (a digest is present) when we should be showing an error saying it is in fact a server side error and should check the logs there. This change will make the error message more accurate for users to look up
Fixes NEXT-1263
the metadata tests have an unnecessarily strict matcher which will fail if the matched metadata isn't the first instance of the element tag type. This will cause a problem when we start to preload bootstrap scripts which will cause preload links in all test cases that did not come from the metadata api itself
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
Filter out the invalid images in metadata og/twitter `images` filter to avoid crash when falsy image slides in.
Add filtering for now as the erroring doesn't show the proper trace pointing to where it's original introduced, might introduce other validation in the future.
## What?
Currently we use 3 separate webpack compilers:
- server
- client
- edge
All of these were creating their own input filesystem (which is used to
read file, stat, etc.). Changing them to share a single inputFileSystem
allows the `cachedFileSystem` to be reused better, as `stat` and
`readFile` can be cached across the 3 compilers.
For the page on vercel.com we've been testing this shaves off 300-400ms
on a cold compile (no cache, deleted `.next`).
<!-- 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 #
-->
---------
Co-authored-by: Shu Ding <g@shud.in>
remaining:
- add tests
caveat: this only works at the route level, we won't inherit from the layout or anything. I think that's fine
Co-authored-by: Florentin / 珞辰 <8146736+ecklf@users.noreply.github.com>
To enable the ability of leveraging current `pathname` and configured `metadataBase` for other canonical like urls, we support those urls with auto resolving with `pathename` and `metadataBase` like canonical url, then you could just configure relative paths like below
```js
openGraph: {
url: './abc', // will be resolved based on pathname and metadata base
},
itunes: {
appId: 'my-app-id'
appArgument: './native-app'
}
```
Fixes#51829
Closes NEXT-1302
Removed an unnecessary dependency mapping from the plugin.
Here's a quick visualization of this change. We have to traversal the module graph twice. The first iteration goes through all server modules and creates the client entries. And the second iteration collects info from all client modules.
Before this PR, the second iteration starts from server entries so it traversals both layers. With this PR, the second iteration will start from client entries only:
<img width="870" alt="CleanShot 2023-06-27 at 10 01 08@2x" src="https://github.com/vercel/next.js/assets/3676859/f0b7a0c6-0ade-483a-8645-48e2a8a6c9d0">
This is a ~100ms improvement for HMR of complicate apps.
### 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 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.
<!-- 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>
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
follow up on #51413 where I kinda forgot to support parsing layout files in sub routes in a parallel segment.
This should fix it by making sure that we check at all level of the app loader tree and by creating an implicit inner `children` for all parallel slot
link NEXT-1301
Currently an "action module" (files with `"use server"` on top) can be
imported by both the server and client layers. In that case, we can't
fork that action module into two modules (one on the server layer, one
on the action layer), but only create it once on the server layer.
This ensures that the action module instance doesn't get forked.
Closes#50801.
fix NEXT-1265
This PR fixes a bug in which the layout files were not picked up if they were direct children of a parallel route slot.
Note: there's a bunch of other files that I've used for debugging that are not used for the test but I'm leaving them for future me.
link NEXT-969
There're 3 layers in the RSC module graph: server → client → action. "Action" means that a Client Component re-enters the server layer by importing a file with `"use server"`, and it should behave the same as the server layer but you can't enter the client layer again (hence we have a 3rd layer name).
Since the action layer has the same behavior and module resolution rules, it should be bundled just like the server layer.
Closes#50658. Originally the issue was that `auth/next` isn't being bundled on the action layer, and it has the async local storage imported. Because of that, that storage comes from node_modules instead of the server bundle.
fix NEXT-1290
Make sure we are using `var` instead of `const` as we always put the new
appended statements to the end of the module body, but they can still be
referenced before in the HOC case in the runtime. This causes a runtime
error.
Tl;dr: `a = 1; var a` is fine, but `a; const a = ...` will result in a
compilation error.
Closes#49344.
Remove the Server CSS manifest and related logic, and use the chunkGroup
CSS files instead for each entry to inject stylesheet links.
Why was that manifest needed in the first place? When implementing CSS
collection for RSC and nested layout initially, we collect CSS imports
at each layer and create corresponding client entries. But then soon got
hit by the problem of duplication and improper tree-shaking. Two layers
can have the same CSS imported so we solved it in a way that "if an
upper layer imports this module, skip it in child layers". Note that
this is deduped by module, so we need to keep the information of "layer
(entry) → CSS modules" somewhere, in a manifest.
Another reason is that we create the client entry before Webpack
optimizes modules, so we can inject the client entry into the same
compilation. But that means the collected client modules from the server
layer are not properly optimized (DCE). **This is a general issue at the
moment that's not specifically related to CSS, although using that
manifest to collect DCE'd info and join the original collected CSS files
with that info temporarily solved it.** That's why I disabled some tests
related to font CSS collection and want to improve it in a more general
way.
Why is that not needed anymore? Main reason is to keep a good balance
between duplication and number of chunks, and delegate the decision to
Webpack's splitChunks plugin. It is not possible to get to a point of 0
duplication unless we ship every CSS module as a single chunk. And since
in #50406 we made the duplication better but at the chunk asset level,
instead of the original module level.
Prior work: #50406, #50610.
### What?
Fixes https://github.com/vercel/next.js/issues/50129
### Why?
The current denormalization of app dir paths doesnt account for the
normalization done in `normalizeAppPath`, causing build log outputs for
certain paths such as anything under a route groups to be incorrect
### How?
There's 2 ways this could be fixed:
1.) Denormalize the app dir paths by reading the
`app-path-routes-manifest.json` and mapping back to the original file
path
2.) (what I chose to do) Normalize the keys of `appBuildManifest`
### Result
App dir paths, including route groups, now have their correct output
size
<img width="494" alt="image"
src="https://github.com/vercel/next.js/assets/93682696/0eee79b8-7d60-4c88-b07a-dfb750aa9592">
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Similar to tags and paths, when `cookies().set()` is called we have to
invalidate the client router cache as well so routes with
`cookies().get()` will not holding the stale data. This is critical for
auth and other scenarios.
In the future we can have an optimization to only invalidate routes that
actually rely on cookies, similar to paths.
This PR fixes a few reports that we were double fetching when navigating via a link that had prefetch false.
## Context
The bug was happening because we were inadvertently eagerly fetching even if we potentially bailed out of the optimistic navigation, which would then trigger another fetch from going through the regular navigation path.
There's potentially another bug here where we should potentially not bail out of optimistic navigation in the cases reported but we can fix that later.
fix#49844
link NEXT-1287
## What?
While looking at the CPU profile of booting up Vercel's site I noticed
that we call `getPageStaticInfo` a lot. Looking into this more it turns
out `getPageStaticInfo` is currently called for all routes, `pages` and
`app`, even though the data is only being used to keep track of which
routes are edge functions, however, this is already tracked as part of
the build output so this didn't make sense to me. First I tried
commenting out this entire block and all tests were passing, so I
removed it except for middleware as middleware can provide a `matcher`
which does need to be known before compiling the file as of right now.
After that change a different set of tests started failing, specifically
the one that checks if we warn correctly. Interestingly by fixing
`getPageStaticInfo` being called early and for all routes it also caused
these warnings to no longer trigger as there was a case in the manifest
plugin that called `getPageStaticInfo` with less information. Calling
`getPageStaticInfo` there was not needed either as we call
`getPageStaticInfo` at the beginning of the build for each entrypoint so
we already have the information required, it just had to be passed down
so that the manifest plugin could use it.
For Vercel's site this change improves booting the dev server by over 1
second.
Related to #48748
<!-- 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?
### Why?
### How?
Closes NEXT-
Fixes #
-->
---------
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
When navigating to a route with a hash parameter, the layout router
jumps to the element by scrolling to the node's `offsetTop` value.
However, this will ignore `scroll-padding`, which deviates from browser
behavior.
It looks like this isn't an issue in the pages router which currently
makes use of
[`scrollIntoView`](https://github.com/vercel/next.js/blob/canary/packages/next/src/shared/lib/router/router.ts#L2262).
Closes NEXT-1171
Fixes#49612
---------
Fixes#50232
Passing down the private env into `'render-server'` module to pick up the proper react with require-hook in standalone server
fix NEXT-1260
Follow up for #50548
There're some packages like `aws-sdk-js-v3` which doesn't have a exports field yet:
```
"main": "./dist-cjs/index.js",
"types": "./dist-types/index.d.ts",
"module": "./dist-es/index.js",
```
This PR let u pick up by the js assets based on main fields, will prefer `"module"` field instead of `"main"`
Closes NEXT-1286
Adding a `_rsc` query for RSC payload requests so that they can be
differentiated on resources level for CDN cache for the ones that didn't
fully respect to VARY header.
Also stripped them for node/edge servers so that they won't show up in
the url
x-ref:
https://github.com/vercel/next.js/pull/49140#issuecomment-1549405009Closes#49140
Closes NEXT-1268
Like how we handled RSC loader transform before, we also apply swc
loader to middleware to make sure the imports optimization is applied so
og package won't be bundled
Fixes#50492
There are some incoming docs / MDX changes where prettier will throw an error when using the older version. Updating prettier before I bring in those changes.
Looks like the most notable change is adding parentheses around `typeof` checks in TypeScript.
**Before**
```
export type Locale = typeof i18n['locales'][number]
```
**After**
```
export type Locale = (typeof i18n)['locales'][number]
```
Encode the state tree where the content could contain unicode when
request the RSC payload, to avoid the fetch failure due to bad encoding
for headers
Fixes#48728
fix NEXT-1258
After enabling Draft Mode, `router.refresh()` was incorrectly causing the page to crash and do a full page refresh.
This PR fixes this case.
Co-authored-by: Steven <229881+styfle@users.noreply.github.com>
For RSC server layer so far we bundle all dependencies, ESM format is the better one rather than CJS to analyze and tree-shake out the unused parts. This PR changes pick the condition names that are in ESM format first for server layer.
Also fixes the misorder of condition names of edge runtime, `conditionNames` should only contain either ESM or CJS, previously the main fields are mixed with conditon names which is not expected for webpack, we separate them now.
Since we're picking ESM instead CJS now, the error of require `exports * from` doesn't exist anymore, but if you're using a CJS dependency which require a ESM package, it will error. This is the existing behavior for our webpack configuration but could happen on server layer bundling
Other related changes:
* Imports are hoisted in ESM, so migrate`enhanceGlobals` to a imported module
* Use `...` to pick the proper imports by import expression, and prefer the `react-server` / `edge-light` condition names for corresponding cases
* Remove edge SSR duplicated `middleware` export checking
This makes sure that if `revalidateTag` is called in a Server Action, the client router cache and prefetch cache are invalidated correctly so following navigations won't reuse the cache that might hold stale data.
Similar case for `revalidatePath`. I left a TODO where we can't just invalidate the subtree under the revalidate paths because of current implementation limitations. To ensure correctness, we just do the same as `revalidateTag`.
When twitter metadata is not provided but opengraph metadata is, fill the opengraph basic information for twitter metadata.
Twitter card can't be displayed if there's no information from twitter meta tags, at least the `twitter:card`. We fill the `title` `description` and `images` these 3 overlapped properties from opengraph image so they can be displayed properly
Closes NEXT-1111
## What?
Anytime you open a Next.js application that doesn't have a `favicon.ico`
you'll notice `/_error` is being compiled because the browser requests
`favicon.ico`. This PR ensures the 404 page is not compiled in
development for that request. It helps a little with compilation speed.
<!-- 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 or adding/fixing 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 #
-->
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Updates to not throw the dynamic server error inside of the patched
fetch as it's typical for fetch errors to be caught and handled and this
error is not meant to be caught by users. This instead throws it during
rendering so we can ensure we catch it instead of users.
x-ref:
https://github.com/vercel/next.js/actions/runs/5182384027/jobs/9339123096
## What?
Recently I've been using these hello-world tests quite often to get the baseline traces out for `pages` and `app`.
Adding them to the repo so that I don't have to recreate / stash them all the time.
This field is no longer needed. Although removing it might cause
unnecessary styles being included that could be tree-shaken potentially,
it solves a more critical issue of missing CSS resources: since now CSS
import can be "hoisted" to its parent entry (e.g. a layout), we can't
simply get all used CSS resources from the "leaf entry" (e.g. a page).
This PR fixes a couple of categories of CSS issues in App Router, that
come from the same root cause.
### 1. Duplicated styles being loaded in different layers
This issue has been described in
https://github.com/vanilla-extract-css/vanilla-extract/issues/1088#issuecomment-1563931144.
If a CSS module (or a global CSS) is referenced in multiple layers (e.g.
a layout and a page), it will be bundled into multiple CSS assets
because each layer is considered as a separate entry.
<img width="1141" alt="CleanShot-2023-05-26-GoB9Rhcs@2x"
src="https://github.com/vercel/next.js/assets/3676859/8e0f5346-ee64-4553-950a-7fb44f769efc">
As explained in that issue, we have to bundle all CSS modules into one
chunk to avoid a big number of requests.
### 2. CSS ordering issues (conflicts)
This is likely causing https://github.com/vercel/next.js/issues/48120.
When the layer-based bundling and ordering logic applies to CSS, it can
potentially cause non-deterministic order. In this example, button A in
the layout should be in blue. However when button B is imported by the
page, button A becomes red. This is an inconsistent experience and can
be hard to debug and fix.
<img width="1090" alt="CleanShot-2023-05-26-Ar4MN5rP@2x"
src="https://github.com/vercel/next.js/assets/3676859/4328d5d7-23af-4c42-bedf-30f8f062d96a">
### What?
This test case was never passing and accidentally enabled for Turbopack.
We could disable the whole test suite, but since only one test case is
affected we can also disable only that one.
## What?
Currently we use the initial compile to add entrypoints that we know are
going to be used in the application. For example the Next.js runtime,
`react`, `react-dom`, and such. While this was the right default when
Next.js only had `pages`, it's no longer true when both `pages` and
`app` exist. E.g. when you're working on a page using App Router we'd
still compile `pages/_app`, `pages/_document`, and `pages/_error` even
though those would not be used. In case of larger applications (e.g.
Vercel's application) this would mean thousands of extra modules being
compiled even though you don't need them for the page you're looking at.
Similarly we'd compile the Next.js runtime for App Router even when
you're only using `pages`.
This PR changes the handling to only compile the entries that are needed
for the current set of visited pages (on-demand-entries). If that set
only includes `app` entrypoints then the `pages` related files will be
excluded. If the set contains both `app` and `pages` both will be
included. Similarly for `amp`, if you don't use `amp: true` / `amp:
hybrid` the development runtime will not be compiled.
📔 Note: This is specifically for webpack, Turbopack already compiles
everything needed lazily so it didn't have this limitation.
#### Before
```
- event compiled client and server successfully in 1079 ms (306 modules)
- event compiled client and server successfully in 155 ms (306 modules)
```
With opening `/`:
```
- event compiled client and server successfully in 1118 ms (306 modules)
- event compiled client and server successfully in 157 ms (306 modules)
- event compiled client and server successfully in 599 ms (486 modules)
```
Total: 1.874ms (Note: This number is much higher when `pages/_app`
imports many modules).
#### After
```
- event compiled client and server successfully in 118 ms (20 modules)
- event compiled client and server successfully in 65 ms (20 modules)
```
📔 Note: opening the page then causes the Next.js / React runtime to be
compiled ofcourse
```
- event compiled client and server successfully in 115 ms (20 modules)
- event compiled client and server successfully in 57 ms (20 modules)
- event compiled client and server successfully in 1137 ms (361 modules)
```
Total: 1.309ms (Note: This number is not affected by`pages/_app`
importing many modules).
## How?
We can only apply this optimization after we've looped over the list of
on-demand entries, as that has the required metadata. Hence why I went
with deleting the keys for each respective type of entrypoint (`pages`,
`app`, `amp`).
<!-- 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 or adding/fixing 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 #
-->
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
This breaks up some of our longest running tests which allows more
parallelizing of the tests. This also moves turbopack tests filtering
back to an allow list as it is running a lot of unrelated tests
currently which isn't ideal. We should only be running against tests
that are explicitly testing turbopack e.g. build tests should not be
duplicated in the turbopack group.
```sh
test/integration/css/test/group-1.test.js: 762.655
test/integration/edge-runtime-module-errors/test/index.test.js: 695.309
test/integration/css/test/group-2.test.js: 671.848
test/integration/i18n-support/test/index.test.js: 518.173
test/integration/scss-modules/test/index.test.js: 451.704
test/integration/css-features/test/index.test.js: 417.318
test/integration/css-modules/test/index.test.js: 403.405
test/integration/eslint/test/index.test.js: 381.563
test/integration/500-page/test/index.test.js: 371.134
test/integration/telemetry/test/index.test.js: 367.691
test/development/acceptance-app/ReactRefreshLogBox.test.ts: 335.878
test/integration/create-next-app/templates.test.ts: 334.01
test/integration/scss/test/group-2.test.js: 327.255
test/integration/scss/test/group-1.test.js: 318.574
test/integration/edge-runtime-configurable-guards/test/index.test.js: 313.834
test/e2e/instrumentation-hook/instrumentation-hook.test.ts: 294.618
test/development/acceptance-app/error-recovery.test.ts: 283.355
test/e2e/app-dir/app/vercel-speed-insights.test.ts: 278.242
test/integration/create-next-app/index.test.ts: 272.442
```
## Problem
Relative hash/query handling in `next/link` (e.g. `<Link
href="#hello">`) is broken in App Router, especially if you're on a
nested route.
This wasn't a problem in `/pages` because the href always get fully
resolved in `<NextLink>`; i.e. if you have `<Link href="#hash" />` on
`/hello`, it'll resolve the href to `/hello#hash` and use that
everywhere.
However, in App Router, `<Link>` no longer uses the current location to
resolve the href:
5451564f36/packages/next/src/client/link.tsx (L450-L457)
Therefore navigating with `new URL(href, location.origin)` will skip the
current path and always apply the relative hash/query to the _root_
route:
5451564f36/packages/next/src/client/components/app-router.tsx (L208-L215)
## Solution
Not 100% sure if this is the best solution, but since `app-router` is
already reading `window.location`, I'm using `location.href` as the base
URL to resolve the href.
I grep'd for `location.origin` and checked other callsites; seems like
only `app-router` deals with user specified hrefs.
Fixes https://github.com/vercel/next.js/issues/42157 &
https://github.com/vercel/next.js/issues/44139, and potentially
https://github.com/vercel/next.js/issues/48554 and
https://github.com/vercel/next.js/issues/22838
## Test Plan
```
pnpm testheadless test/e2e/app-dir/navigation
```
---------
This adds new `build and test` and `build and deploy` workflows in favor
of the existing massive `build, test, and deploy` workflow. Since the
new workflows will use `pull_request_target` this waits to remove the
existing workflow until the new one is tested.
While testing this new workflow flakey behavior in tests have also been
addressed. Along with the new workflow we will also be leveraging new
runners which allow us to run tests against the production binary of
`next-swc` so this avoids slight differences in tests we've seen due to
running against the dev binary.
Furthermore we will have a new flow for allowing workflow runs on PRs
from external forks which will either require a comment be checking a
box approving the run after each change or a label added by the team.
The new flow also no longer relies on `actions/cache` or similar which
have proven to be pretty unreliable.
Tests runs with the new workflow can be seen here
https://github.com/vercel/next.js/actions/runs/5100673508/jobs/9169416949
Since the static metadata routes should always be static that can be
optimized, they should be marked as default runtime (or basically no
runtime). This PR change the runtime detection, if it's a static
metadata route file, its runtime will be erased.
So that it won't be picked up by `edge-app-route-loader` and then by
`next-image-loader` which emits the unexpected static file
Fixes NEXT-1238
If using Server Actions on the client layer without enabling the
`serverActions` feature, the build should error. Add a test case to
ensure #50199 works.
Since there is no longer a limitation that requires us to static analyze
`process.env`, this PR removes it from the build process and updates the
corresponding documentation.
### What?
This reverts commit 6ebc725fe6 / #50247.
### Why?
#49972 is reverted due to bugs, and I'm retrying it.
### How?
Closes WEB-1072
Closes WEB-1097
Closes NEXT-1156 (as it's reopened by the revert PR)
fix#48469
---------
Co-authored-by: Shu Ding <g@shud.in>
### What?
Implement a CJS optimizer for next-swc
### Why?
x-ref: https://vercel.slack.com/archives/C02HY34AKME/p1684341093462309
Assuming most CJS files are transpiled from ESM, we can mimic
tree-shaking using an AST transform.
### How?
Closes WEB-1072
Fixes#48469
fix NEXT-1156
---------
Co-authored-by: Shu Ding <g@shud.in>
Fix react and react-dom aliases are not properly set for `pages/`
* Remove alias react-dom internals to `{}` in edge runtime as we're using server rendering stub as alias
* Add `react$`, `react-dom$` missing aliases
* Only apply alias to builtin react/react-dom when it's app dir assets.
* Add `react|react-dom/package.json` resolving to require-hook
* Fix hmr issue that sometimes it will perform a reload when a hard navigation is triggered
Currently the edge runtime does not support static generation so this adds a warning when `force-static` is leveraged with `edge-runtime` as it will cause unexpected behavior. Support is being investigated so this isn't a hard error at the moment.
x-ref: [slack thread](https://vercel.slack.com/archives/C03S8ED1DKM/p1684783403551589)
## What?
After landing #49855 I found a few more edge cases with not-found not
behaving as expected:
- When navigating directly to a not-found page (e.g. `/testabc`) the
error boundary would not reset as there were multiple levels being
triggered at the same time.
- When running in production navigating back/forward to the not found
page caused the page to become empty
Both issues are fixed by this PR. I've added tests for both.
## How?
- Ensures `asNotFound` is not set on the layout-router, it causes all
levels to trigger not-found, even though only app-router needs it
- Ensures navigations to 404 are always a mpaNavigation (browser
navigation) instead of trying to do a client-side navigation (mirrors
what we do in `pages`)
Fixes NEXT-1209
Fixes NEXT-1218
Fixes#49823
<!-- 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 or adding/fixing 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 #
-->
client refs are not correctly extracted as we're using regex to get the exports names from cjs file. The regex was extracting some bad names from the code source, this PR fixes the regex to make sure they extract the correct content
Fixes NEXT-1213
As explained in the comments, the `cookies()` API is a mix of request and response cookies. For `.get()` methods, we want to return the request cookie if it exists. For mutative methods like `.set()`, we return the response cookie type instead.
fix#50049
fix NEXT-1211
Currently the suffix logic is for pages so nothing happens in app dir. This PR changes it to **always** apply the `createSuffixStream(closeTag)` transform, to defer `</body></html>` to the end of the stream.
fix#48372
fix NEXT-1200
* Adding default metadata to root not found under root layout
* Refactor the tests a bit, previously it only checks if the text existed in html, it actually exisits in flight response
Fixes#49979
Closes NEXT-1207
For static member expressions like `foo.bar`, we currently treat it as one whole Ident `foo.bar` and pass it over the `$$bound` array as one value. That causes a problem where the Ident inside the function body needs to be converted, because it can no longer access to `foo`.
Closes#49985.
fix NEXT-1206
## What?
@steven-tey noticed that on upstash.com that scrolling to hash keeps
happening regardless of the hash being set:
- Open site
- Click `Pricing` which adds `#pricing` and scrolls to the
`id="pricing"`
- Click `About`
- Click on the logo
You'll notice that navigating back to the homepage ends up scrolling to
the `id="pricing` instead of to the top of the page.
## How?
This happened because we didn't reset the `hashFragment` and
`segmentPaths` for scrolling when scroll was applied, which means it
would keep that value in the state and would be applied as such on
navigation.
This PR ensures that besides setting `apply` to `false` we also reset
the `hashFragment` and `segmentPaths`.
Fixes NEXT-1205
<!-- 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 or adding/fixing 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 #
-->
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
This PR fixes a warning that previous looked like the following:
```
Warning: fetch for [object Request] specified "cache: default" and "revalidate: 60", only one should be specified.
```
