Scope all `serverActions` config in one group "serverActions" to make it
more semantics
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Rather than sending a warning, we should fail the build if a postpone
call is caught. We should also fail the build if there are any errors
during static generation similar to the non-ppr case.
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
With Barrel Optimization, we are trying to "shortcut" the import to be
directly pointing to the final target, as barrel files shouldn't have
any side effects. However, there could be `"use client"` and `"use
server"` directives which we can't ignore. Hence we must apply the
`serverComponents` transform of SWC to these barrel files too.
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
### What?
Adds support for Server Actions imported by both server and client.
### Why?
If an Action is imported by both the Client and RSC layers, we need to
support them as if they're the same action.
### How?
First, we need to ensure both layers create the same action hash ids,
which we can then use to deduplicate actions imported by both layers. If
a conflict is found, we prefer the RSC layer's action.
Closes WEB-1879
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
There could be CSS files emitted in these chunks so both manifests need
to filter them out. This fixes `app dir - css css support chunks should
bundle css resources into chunks`.
### Why?
breaks hmr and causes some duplicate react instances (it was also
supposed to fix some of those, seems neither version is correct)
Closes WEB-1882
### What?
[1] Use camelCase for SVG properties
[2] Catch expected error in cookie functions
### Why?
[1] Prints error to the console
[2] If the cookies `set` or `delete` methods are called in a Server Component, an error is thrown
### How?
[1] Change property names from kebab-case to camelCase
[2] Catch error
This PR enables the `experimental.webpackBuildWorker` to be on by
default. This flag enables logic inside Next.js to run the compilation
in an isolated worker. The reason for this is that the webpack
compilation process retains a lot of memory for the whole duration of
the build process because it uses some packages that leak. We don't need
it for the rest of the process so it's best to use it in a worker and
leave the memory to be used for static generation.
This will improve memory usage during build, avoiding OOMs caused by
webpack exceeding memory.
<!-- 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: JJ Kasper <jj@jjsweb.site>
### What?
Changes Server Actions to use a lazy `require()` statement instead of a
lazy dynamic `import()`, to fix SA in the Edge runtime.
### Why?
The Edge runtime has a restriction that it's not allowed to lazy load
more files. The problem is that dynamic `import()` does exactly that, it
defers importing those files until the call time. `require()` doesn't
have this issue, because the chunks it would load are included instead
of deferred.
### How?
Just needed to modify the actions loader entry point… after hours of
trying to get the action loader to evaluate in the node runtime and then
import the actions in the edge runtime.
Closes WEB-1874
when calls to `maybePostpone` throw but there's no postpone state, we want to handle those errors differently so that we can provide clearer messaging around how to prevent them, while still retaining any errors that were re-thrown by the user.
ex:
This PR removes the wasm target for the next-swc build for the next major version. The main motivation is that Turbopack does not support targeting wasm yet, and it would be a significant amount of work to add. We plan to make Turbopack the default zero-config experience in a minor version, possibly before we are able to support a wasm target, so we need to make this breaking change now. We also plan to make more improvements to the webpack experience with shared Rust code, which we have so far been blocked from implementing because of the current wasm restrictions. We would like to support a wasm target again in the future, but cannot say at this time when that would be.
Closes WEB-1865
Apply react-server condition and related API checks for pages API.
if you're doing react SSR with renderToString in middleware it should be disallowed. Imaging it could send the rendered html code to client and you display it in browser. But it might require hydration so it can be broken.
Follow up for #57448 , same reason explained in #57448
Closes NEXT-1653
### What?
We have to walk the directory tree recursively for every page (instead
of once) to get the correct loaderTree.
With this PR we walk the directory tree and for every
`page.(js,jsx,ts,tsx)` (entrypoint) we find we walk it again to get the
loader tree for that page
Closes WEB-1868
Closes WEB-1609
We also don't warn for awaiting a Promise late. That's a fine pattern in
Next.js because it allows for fetching early and awaiting late.
If a Promise does reject before that we still log an error which is fine
because an error actually did happen even if we didn't await it.
We ignore postpones though because they are not unexpected.
---------
Co-authored-by: Jimmy Lai <laijimmy0@gmail.com>
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Reduce the times that we re-create loaders, down to 3 loaders:
* swc loader for server layer
* swc loader for client layer
* babel loader
This change let us only create some loaders for once, and make the code
easier to read.
`babelLoader` will only available when babel config is enabled, so we
use filters to skip it when it's empty.
### What
Fixes how to determine if given route is dynamic to match next-dev does:
462b8585b6/packages/next/src/lib/metadata/get-metadata-route.ts (L79)
We were passing calculated route instead to check if it's dynamic, so
`/sitemap` always considered as static since calculated route is
`/sitemap.xml`.
Closes WEB-1864
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Apply `react-server` resolving and server components invalid APIs
checking to middleware. We want to limit the react usage in in
middleware as so far it's not aimed for rendering purpose.
Another invalid case could be: if you're doing react SSR with
`renderToString` in middleware it should be disallowed. Imaging it could
send the rendered html code to client and you display it in browser. But
it might require hydration so it can be broken.
This PR will only let you import `react-server` export condition
packages.
### What?
Fixes Client -> RSC (client importing a `"user server"` file) Server
Actions that are using TS.
### Why?
### How?
I check if the source module is using TS before "processing" the module
into the RSC layer.
Closes WEB-1871
This PR adds the codemods transforming certain fields from `metadata`
export to `viewport` export, will still preserve rest metadata export
properties. We don't cover `generateMetadata` to `generateViewport` as
there might be more complex logic inside the function which is hard to
apply the codemods rules.
TLDR: Codemods for #57302
* Should show `ImageResponse` is deprecated if you still import from `"next/server"`
<img width="708" alt="image" src="https://github.com/vercel/next.js/assets/4800338/38f9b9db-2cfb-48ec-99cc-08e7d1477155">
* If you build it will fail to compile, this might not be super ideal but at least it's not working. For pure js it will throw errors.
```ts
./app/icon.tsx:7:10
Type error: Only a void function can be called with the 'new' keyword.
5 |
6 | export default function icon() {
> 7 | return new ImageResponse(
| ^
8 | (
9 | <div
10 | style={{
ELIFECYCLE Command failed with exit code 1.
```
This PR updates the build output in order to reflect the changes brought
by PPR and also to make it more consistent.
before
```
○ (Static) automatically pre-rendered as static HTML
◐ (Partially Pre-Rendered) static parts of the page were pre-rendered and the dynamic parts will be streamed
ℇ (Streaming) server-side renders with streaming (uses React 18 SSR streaming or Server Components)
λ (Server) server-side renders at runtime (uses getInitialProps or getServerSideProps)
```
after
```
○ (Static) prerendered as static HTML
◐ (Partial Prerender) prerendered as static HTML with dynamic server-streamed content
λ (Dynamic) server-rendered on demand using Node.js
ℇ (Edge Runtime) server-rendered on demand using the Edge Runtime
```
<!-- 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 #
-->
