Previously `next-swc` had relay transform inline, but it makes
maintenance harder. So this PR patches next-swc to use relay plugin from
`swc-project/plugins` repository.
Closes WEB-782
Fixes#47239
fix NEXT-883 ([link](https://linear.app/vercel/issue/NEXT-883))
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))
This PR addresses two bugs:
- The parameters of arrow functions were not being tracked in `closure_idents` due to not being visited via `visit_mut_param`. They are stored as `Vec<Pat>` instead so we need to handle these as a special case.
- The rest parameter could not be transformed into `...r = closure[1]`, so we changed that case to `r = closure.slice(1)`.
fix NEXT-874 ([link](https://linear.app/vercel/issue/NEXT-874))
Fun! This depends on https://github.com/vercel/turbo/pull/4251 to
implement streamed Node evaluations, giving us the ability to support
streamed middleware responses.
This is just the first step to supporting RSC streaming in Turbopack. I
chose to start with this because it requires all the same base logic,
and I understand the full router->middleware->HTTP server code path, so
it's a lot easier to work on.
Fixes WEB-738
When using a "use server" module, only exporting async functions is
permitted. However, since we cannot perform static analysis on all
exported value types (e.g., `export const foo = condition ? A : B`), we
have added a runtime ensure function to validate that these are indeed
valid functions.
By implementing this, we can prevent any strange errors like "Can't
access $$typeof of undefined or null" that may arise when exporting
`undefined` or `null` from a server entry. Moreover, this measure helps
avoid any potential mistakes that may occur.
fix NEXT-865 ([link](https://linear.app/vercel/issue/NEXT-865))
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
This PR is largely preparation work for next/font/local by
compartmentalizing and modularizing existing pieces of next/font/google.
It:
* Renames the top level directory to `next_font`
* Places next/font/google-specific code into `next_font/google`
* Extracts common structures and methods into top-level
`font_fallback.rs`, `stylesheet.rs`, `util.rs`, etc.
* Updates visibility of structures and functions to use `pub(super)`
within `next/font/google`
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
The old `test_generator::test_resources` could only find resources relative to the project root, and not relative to the test file. Because of the new nextpack directory structure, this causes all kinds of headaches between running in nextpack and running in turbo (`next.js/packages/next-swc` vs `nextpack/next.js/packages/next-swc`).
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))
* Rename client reference plugins from `Flight*` to `ClientReference*`
* Rename `serverComponentManifest` to `clientReferenceManifest`
* Group the key/value in client reference manifest
* Update turbopack crates
fix NEXT-827 ([link](https://linear.app/vercel/issue/NEXT-827))
This aligns use of the next/font transform across the workspace under a
single crate, now called `next-transform-font`.
### What?
Improve the UX of the error overlay
### Why?
* error overlay doesn't reopen when closed, but new error appear
* error overlay shows non-actionable warnings in node_modules
* error overlay shows unrelevant errors in node_modules
### How?
* low priority for errors in node_modules
* hide node_modules warnings
* open error overlay on new error
* Also updated the files I touched to the next.js prettier format
fixes WEB-712
fixes WEB-713
fixes WEB-714
fixes WEB-727
Co-authored-by: Leah <8845940+ForsakenHarmony@users.noreply.github.com>
This PR makes sure that we are not appending statements after the function or arrow expression, if they're actions. Instead we put all them in a `ParenExpr` so the entire thing can be defined inline.
fix NEXT-813 ([link](https://linear.app/vercel/issue/NEXT-813))
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)).
Builds on https://github.com/vercel/turbo/pull/4202 to implement custom Next.js Transformers in Turbopack.
This is the final piece to moving the `next-*` crates to Next. While we've _technically_ moved everything, Turbopack didn't support running custom transformers. So we're actually stuck on the last version we cut before deleting the next crates, running the transformers that exist in the turbopack repo. With the new support, we're almost back to the tip of main branch (there's still some snafu with `swc_core` upgrading that I'm working on).
Co-authored-by: Tobias Koppers <1365881+sokra@users.noreply.github.com>
### What?
enables the next-dev-tests crate integration tests from trubopack
### Why?
to unblock the move PR we temporarily disabled the tests
### How?
Fix the new location and fix the expect dependency
Fixes WEB-708
---------
Co-authored-by: Justin Ridgewell <justin@ridgewell.name>
It will be crucial to detect these common problems and abort compilation, because it's intended to be using a server boundary but these problems might cause it ending up in the client.
Fixes NEXT-762.
