ecef83ac61
When we apply `createActionProxy` twice to the same value, it currently errors because we can't override the ID of it. This PR makes sure that 1) when the value already have an ID defined, we skip setting it again; 2) all the action IDs are being tracked even for duplicated ones. Note that it's technically impossible to "detect" the duplication here (via static analyzation) and only set it once. For example: ```ts 'use server' export async function foo () {} export const bar = a_value_we_dont_know_yet ? foo : async () => {} ``` So, the compiler will always wrap `createActionProxy` for every exported value and assume they're different Server Actions (hence different IDs). With this fix, if we find that it's already defined before, we just return the defined reference as they're strictly identical so the ID does't matter. Closes #54655, closes #61183. Closes NEXT-2264 |
||
---|---|---|
.. | ||
crates | ||
native | ||
package.json | ||
README.md |
@next/swc
This package is responsible for swc compilation customized for next.js
Development
Run tests
cargo test
# Update snapshots and fixtures for tests
UPDATE=1 cargo test
Format code before submitting code
cargo fmt
Build the binary to integrate with next.js
pnpm build-native
Build wasm bindings to integrate with next.js
pnpm build-wasm
napi bindings feature matrix
Due to platform differences napi bindings selectively enables supported features. See below tables for the currently enabled features.
arch\platform | Linux(gnu) | Linux(musl) | Darwin | Win32 |
---|---|---|---|---|
ia32 | a,b,d,e | |||
x64 | a,b,d,e,f | a,b,d,e,f | a,b,d,e,f | a,b,d,e,f |
aarch64 | a,d,e,f | a,d,e,f | a,b,d,e,f | a,b,c,e |
- a:
turbo_tasks_malloc
, - b:
turbo_tasks_malloc_custom_allocator
, - c:
native-tls
, - d:
rustls-tls
, - e:
image-extended
(webp) - f:
plugin
Package hierarchies
@next/swc
consist of multiple rust packages to enable features. See below for the high level hierarchies.
flowchart TD
C(next-custom-transforms) --> A(napi)
C(next-custom-transforms) --> B(wasm)
D(next-core) --> A(napi)
E(next-build) --> A(napi)
F(next-api) --> A(napi)
C(next-custom-transforms) --> D
D(next-core) --> F(next-api)
D(next-core) --> E(next-build)
next-custom-transforms
: provides next-swc specific SWC transform visitors. Turbopack, and the plain next-swc bidnings (transform
) use these transforms. Since this is a bottom package can be imported in any place (turbopack / next-swc / wasm), it is important package do not contain specific dependencies. For example, using Turbopack's VC in this package will cause build failures to wasm bindings.next-core
: Implements Turbopack features for the next.js core functionality. This is also the place where Turbopack-specific transform providers (implementingCustomTransformer
) lives, which wraps swc's transformer in thenext-custom-transforms
.next-api
: Binding interface to the next.js provides a proper next.js functionaility usingnext-core
.napi
/wasm
: The actual binding interfaces, napi for the node.js and wasm for the wasm. Note wasm bindings cannot import packages using turbopack's feature.
To add new swc transforms
- Implements a new visitor in
next-custom-transforms
. It is highly encouraged to useVisitMut
instead ofFold
for the performance reasons. - Implements a new
CustomTransformer
underpackages/next-swc/crates/next-core/src/next_shared/transforms
to make Turbopack's ecma transform plugin, then adjust corresponding rules inpackages/next-swc/crates/next-core/src/(next_client|next_server)/context.rs
.