For the server compilation, we currently transpile the dynamic import
expression to `null` if `ssr` is disabled. However to make the Server
Actions layer work (as it can be created again from a Client Component),
we can't do that optimization.
This PR changes it to always keep that import expression when
`react_server_components` (App Router) is enabled, no matter which layer
it's on.
Closes#52672.
When `"use client"` directive appears after other statements, it should
be ignored instead of treat as client components. There's a bug inside
swc transform that we should mark the directives detection is "finished"
after other non string literals directives AST nodes are detected before
the first directive
x-ref:
https://github.com/vercel/next.js/pull/54358#discussion_r1300740950
Similar to #54004, this PR changes `private-next-rsc-action-validate`
and `private-next-rsc-action-client-wrapper` to export named values
instead of default values. In #54230 (currently broken), the Server
Action file was bundled via Vite/Rollup as an external dependency so
we're not doing the ESM interoperation correctly.
Closes#54230.
### What & Why
Add base path handling for the url in redirect error if the `basePath` is configured.
This is only break for server rendering case as the `basePath` is missing in the `Location` header. When running `next build`, everything is managed well with app router and base path on client side so it didn't break.
### How
Adding `basePath` if it's presented for `Location` header.
Update the `RenderOpts` type as basePath is already passed down in it, also update them for turbopack entries
Fixes#54163
Closes NEXT-1529
This fixes the compilation of `export { action as renamed }` syntax. Previously it's compiled as `export var action = ...` and with this fix, it will be `export var renamed = ...`.
Closes#54229.
### What?
Strip the relative path prefix (`_next/`) when generating the `PageLoaderAsset`. This is necessary because the page loader will internally use `__turbopack_load__`, which prepends the prefix back onto the path.
### Why?
Without this, we'd try loading `_next/_next/path/to/file.js`, because we'd prepend the prefix onto a path that already contains it.
### How?
When generating the page loader asset, we "proxy" the `OutputAsset` onto a path which has the prefix removed.
~~Depends on https://github.com/vercel/turbo/pull/5717~~
Closes WEB-1377
Note: depends on next Turbopack publish
https://github.com/vercel/turbo/pull/5487 exports a reusable `handle_issues` function for reporting issues and erroring when failing issues are encountered.
This uses it for `next build` with a failing severity level of error.
This PR changes the internal `createActionProxy` util from a default
export to a named export, as the default export could be problematic if
it's built without the "esModuleInterop" step.
---------
Co-authored-by: Balázs Orbán <info@balazsorban.com>
### What?
This PR makes it easier to use Next.js with IPv6 hostnames such as `::1` and `::`.
### How?
It does so by removing rewrites from `localhost` to `127.0.0.1` introduced in #52492. It also fixes the issue where Next.js tries to fetch something like `http://::1:3000` when `--hostname` is `::1` as it is not a valid URL (browsers' `URL` class throws an error when constructed with such hosts). It also fixes `NextURL` so that it doesn't accept `http://::1:3000` but refuse `http://[::1]:3000`. It also changes `next/src/server/lib/setup-server-worker.ts` so that it uses the server's `address` method to retrieve the host instead of our provided `opts.hostname`, ensuring that no matter what `opts.hostname` is we will always get the correct one.
### Note
I've verified that `next dev`, `next start` and `node .next/standalone/server.js` work with IPv6 hostnames (such as `::` and `::1`), IPv4 hostnames (such as `127.0.0.1`, `0.0.0.0`) and `localhost` - and with any of these hostnames fetching to `localhost` also works. Server Actions and middleware have no problems as well.
This also removes `.next/standalone/server.js`'s logging as we now use `start-server`'s logging to avoid duplicates. `start-server`'s logging has also been updated to report the actual hostname.
The above pictures also demonstrate using Server Actions with Next.js after this PR.
Fixes#53171Fixes#49578
Closes NEXT-1510
Co-authored-by: Tim Neutkens <6324199+timneutkens@users.noreply.github.com>
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
### What?
We change the not-found rendering strategy to the origin one which recovers the not found error from the flight data, and hit the error boundary to display the closet not found component.
For parallel `@slot` we shouldn't pass down the not-found boundary, the boundary is only for `@children`.
### Why?
We're having a lot of not-found matching issues that manually searching for not found and layout won't be accurate as we have various scenarios like `(group)` routes, dynamic routes, etc.
### How?
Only render html with empty body so that the error can recover from flight and render the proper not-found component during hydration.
One change for metadata is that we need to get the "not-found" metadata in the initial render, so we'll catch the not-found error once there first and start render the "not-found" metadata and put it in the flight data. Then when it recovers it's still preserved.
Fixes#53694
### What?
Updates the new `entrypoint.changed()` method to signal whether the server or client assets changed. Now, a `{ changed: 'server' | 'client' | 'both' }` will value will be yielded by the subscription.
### Why?
So that client-only changes can be handled differently than server-only changes.
### How?
We just needed to track the server and client output assets separately, so that we can detect changes to either individually. It's difficult to tell what `Vc` change triggered a recomputation on the Rust side (I'd have to involve mutable `State` into the Vc), and it's also hard to re-emit a duplicate value (eg, if a client change follows a client change, we need 2 emits). Instead, I tie the two different `server_changed()` and `client_changed()` functions into a single enum on the TS side.
Depends on https://github.com/vercel/next.js/pull/53809, since I don't want to introduce merge conflicts while Tobias is on vacation.
This implements a MVP of HMR. HMR works similarly as in turbopack-dev-server, but instead of going through the router to retrieve output assets, output assets are eagerly stored into a global hash map, and retrieved directly from there (see `VersionedContentMap`).
This will require some more glue on the Next.js side in order to handle:
* RSC headers;
* handling Turbopack subscriptiob HMR events from the Next.js WS server, proxying them to `hmr_events`, and sending back the stream of updates.
There's currently no way to evict deleted output assets, nor to communicate these events to the client. @sokra mentioned the `VersionedContentMap` could store a list of assets per entrypoint, instead of having a top-level flat map.
Co-authored-by: Tobias Koppers <1365881+sokra@users.noreply.github.com>
