## What?
Removes `experimental.appDir` this was leftover from when I flipped the
switch.
Kept the config file as in the future we might add future flags and
such. It also helps that it has the types comment included so you always
get types.
<!-- 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 fixes an existing bug where there're Server Actions defined in both the "server" and "client" layers (client imported Actions). They have the same worker name as they exist in one route entry, but they're built into different modules and compiled differently (server and client layers). Because of that, each route entry can have 2 "action module entries".
This PR adds the logic to differentiate that via a "layer" field so they don't conflict.
This uses the new built-in progressive enhancement features of React.
These always use `multipart/form-data` atm. When one comes in that's not
a fetch, we can use `decodeAction` to get a resolved function.
This also ensures that we can test this by passing disableJavaScript to
tests. This disables JS for the context.
Adds proper `multipart/form-data` handling in the Edge runtime and fixes a bug (previously we are always using `serverActionsManifest.node`). For the form data, we just use `await webRequest.request.formData()` for now and will handle streaming later.
For edge runtime, we're modifying `res.statusCode` in actions handler, but we didn't forward the `res` object to it, previously we're using a fake `res` `{}`. This PR fixes it so that the propery status code will be returned to the client
[slack-thread](https://vercel.slack.com/archives/C052S77L05C/p1682988777740609)
This PR renames `experimental.experimentalReact` as
`experimental.serverActions` and makes it a hard compilation error if
it's not set but detected server actions.
This PR changes `mutableCookies` from `RequestCookies` to a
`ResponseCookies` instance, and it now accepts extra options for each
cookie. Take a look at the tests for more details.
cc @styfle
---------
Co-authored-by: Steven <steven@ceriously.com>
Similar to #47922 but based off the latest server implementation and #48626:
> This PR implements the MutableRequestCookies instance for cookies() based on the current async context, so we can allow setting cookies in certain places such as Server Functions and Route handlers. Note that to support Route Handlers, we need to also implement the logic of merging Response's Set-Cookie header and the cookies() mutations, hence it's not included in this PR.
>
> fix [NEXT-942](https://linear.app/vercel/issue/NEXT-942)
This PR also adds the same support for Custom Routes.
cc @styfle.
fix NEXT-942, fix NEXT-941.
We currently use `URLSearchParams` to represent `FormData` but it's not really the same thing. And in Node.js 16 there's no `FormData` available so we can polyfill it via Undici.
Currently POST requests to `"use server"` entries are not correctly
handled, and this PR partially fixes the behavior. Note that the
`isMultipartAction` case is still missing as we can't simply use
`busboy`. Later we'll unify the implementation here to always use
FormData via Undici.
Fixes NEXT-1026.
For now, this isn't a strong requirement as normal `fetch` requests will
still work with `react@next`. But in the future, form related props e.g.
`action=` and `formAction=` requires the experimental build.
Fixes NEXT-954.
Revert some code in #47379 and finalize HOC support. We should require
the HOC to return a "use server" function, so there's no need to compile
the function call specially now.
To make that wrapping logic work, we need to allow passing a server
reference to another server reference. This usually happens in the
function closure in the HOC case, but ideally it's also allowed to
directly pass it as an argument. This requires adding React server DOM's
`encodeReply` and `decodeReply` and other corresponding changes,
including adding `busboy` (can probably be vendored?) as we need to
parse the multipart body now.
fix NEXT-808 ([link](https://linear.app/vercel/issue/NEXT-808))
([link](https://linear.app/vercel/issue/NEXT-808))
When calling the server (via `callServer`), we concat all closure values
(`$$bound`) and arguments of the function call into one array on the
client. Hence on the server, we will have to compile the function
differently to support that.
With this change, the compiled function will have a `$$with_bound` flag
to indicate that if it accepts closure values. If so, the only argument
passed will be an array like `[...bound_values, ...fn_args]`, and we
compile the function parameters to `(closure, arg1 = closure[N], arg2 =
closure[N + 1], ...)` where `N` is the number of the closure
identifiers. This way we can still fill these arguments by only pass an
"bound + args" array. If it doesn't accept closure values, it will be
directly called with `...fn_args` so no compilation change needed.
The reason that we use `arg1 = closure[N]` is that this can support
complex patterns in parameters such as `f(closure, {a} = closure[1], [b]
= closure[2])`.
fix NEXT-487 ([link](https://linear.app/vercel/issue/NEXT-487))
In short, this PR adds a 3rd layer to the server compiler. This extra
layer is for marking the modules when re-entering the server layer from
a client component. It is almost identical to the existing server layer
and it should have all the same bundling and runtime behaviors, but it's
still special because it's not allowed to enter the client layer again
from there.
Because of that, we create the extra entry for that new layer when the
client layer compilation finishes in the `finishModules` phase. The new
entry is handled normally as it's in the server layer. But the original
module in the client layer will be compiled specially as special no-op
exports, and will then be connected via the `callServer` wrapper.
fix NEXT-809 ([link](https://linear.app/vercel/issue/NEXT-809)).
This moves the position of action handling so it can continue page
rendering afterwards. And a `asNotFound` option is added to
`LayoutRouter` to indicate the router to opt into the root not-found
boundary, so not found pages can be programmatically rendered instead of
relying on route mismatching (this is also needed by NEXT-463 later).
Fixes NEXT-467.
This PR adds the support for unnamed default export expression support
`export default async function () {}` in a "use server" entry, with
corresponding test.
Also fixed an existing bug that the default exported action's name
should be aligned with the export name, which is `"default"`.
Closes NEXT-769.
Since we have 2 server compilers (node and edge), the `serverActions`
object will always get overridden by the second compilation during `next
build`. Like the client reference manifest, we need to have 2 objects
for each compiler and merge them when outputting the asset.
Besides that, to avoid `export default` being tree-shaken as unused
export, I changed the loader to use CJS `module.exports` instead. Can't
easily figure out a proper way for now but we plan to create separate
worker for the action endpoint and this will be gone then.
Fixes NEXT-759, read NEXT-761 for the full future plan.
## Bug
- [ ] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the
feature request has been accepted for implementation before opening a
PR.
- [ ] Related issues linked using `fixes #number`
- [ ]
[e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
