### 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.
5.0.0-canary-7118f5dd7-20230705 includes a new [lint error for hook calls inside an async component](7118f5dd7b), a common mistake when refactoring Server Components to Client Components, or vice versa.
This updates the dependency in eslint-config-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
- 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?
- Use a `cssModules` option to configure the `next-flight-css-loader.ts`
based on the match resource.
- Added types
- Ran prettier
### Why?
NextJs supports css modules and global css files.
The `next-flight-css-loader.ts` is capable of dealing with both formats.
However under the hood the loader shares almost no code for css modules
and global css files.
To branch into the correct behaviour the `next-flight-css-loader.ts`
checks the extension of the file using
`this.resourcePath.match(/\.module\.(css|sass|scss)$/)`.
`this.resourcePath` does not include the information from webpacks `!=!`
import syntax.
One solution would be to use `this._module.matchResource` instead of
`this.resourcePath`.
But imho passing it from the webpack.config.js instead of duplicating
the css module file regexp felt cleaner.
### Further questions
- Should we update the loader banner comment?
- Can we drop `this.data.__checksum` in the pitch loader function for
css modules? (it would speed up css modules and for me it looks like it
isn't needed anymore for css modules because of
2eeb0c7f49
(4. April by @shuding)
- Should we split the loader into two loaders?
Fixes#52208
---------
Co-authored-by: Shu Ding <g@shud.in>
The current message isn't very clear about `"use server" function` and
`"use server" file`, and there's no link to docs to explain it further:
```
"use server" functions are not allowed in client components.
You can import them from a "use server" file instead.
```
This PR makes it a bit more verbose:
```
It is not allowed to define inline "use server" annotated Server Actions in Client Components.
You can either mark the entire file by putting "use server" at the top, or pass them down through props from a Server Component.
Read more: https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions#with-client-components
```
## What?
Uses a pre-created regex instead of having webpack run path-to-regexp on the list of patterns. Saves a few milliseconds.
Adds `node_modules` to ignored in order to skip a lot of stat calls at the end of the compilation.
This will likely have a big impact on applications using Yarn PnP as each stat call causes a lookup through `.pnp.cjs`.
I read the PR checklist, but this is such a small PR that I feel it's
self-explanatory.
I believe the wrong function name (`generateMetadata`) is used on this
page, and it was meant to be `generateImageMetadata`.
If not... apologies 😅
### 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>
As discussed in https://vercel.slack.com/archives/C03ENM5HB4K/p1687999628589119 and #51910, it makes sense to have a known list for packages (mostly polyfills) that we know are having dynamic code (`eval`, `new Function`) but are safe to run in the Edge Runtime because that dynamic code will never be executed.
### 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?
Ensures the router instance passed for `next/navigation` in Pages Router is a stable reference. For App Router the router instance is already a stable reference, so making this one stable too would fix#18127.
## How?
Added `React.useMemo` around `adaptForAppRouterInstance`, previously it was recreated each render but that's not needed for this particular case. The searchParamsContext and pathnameContext do need a new value each render in order to ensure they get the latest value.
Fixes#18127
Fixes NEXT-1375
### 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>
### What?
Add all passing tests
### Why?
We enforced that they all run turbopack and these are passing.
If any of these tests would become red, that indicated a problem.
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">
### Issue
When you edit .env* files, the pages under app dir that using env vars are not triggering hot reload
### Fix
Triggering serverComponentChanges hot reload action when we detect env or tsconfig related change. There's a time period that we need to wait before the compilation is finished. First we save a flag `reloadOnDone` if we need to reload when after compilation is done, by determining if `envChange` is `true` (we already know this in dev server). Then in the compilation hooks, we refresh RSC page once it's finished.
### Extra change
since we're checking `event.action` in client hot reloader, and throwing error for unknown action, filter devPagesManifestUpdate out from unexpected action as it sometimes triggered as error in console. Introduced in #51516
Fixes NEXT-1261
In the dev server, we need to call `getStaticInfoIncludingLayouts` for the middleware file to extract its `matchers` field. However, that's currently executed in both app and pages workers. This method is expensive as it depends on the SWC binary to be loaded.
This PR changes it to invoke it as an IPC method, so only the router worker (which runs the compilation) loads SWC, instead of all 3 of them.
This also fixes duplicated console messages of:
```
Using locally built binary of @next/swc
```
For our test app, I'm seeing a 150~250ms improvement:
Haven't measured about the memory impact yet, but it should be a lot.
