History

Benjamin Woodruff c0562529db next-swc-napi: Remove "plugin" from default feature list (#66380 ) Effectively a revert of https://github.com/vercel/next.js/pull/66006, but: - Keeps the cleanup changes from that PR. - With https://github.com/vercel/nextpack/pull/106 removing the explicit `--features plugin` flag, we will match behavior between cargo's defaults and the nextpack development scripts (which we want to do for maximizing cache reuse). The tradeoff here is faster cold builds, at the cost of waiting longer when you want to test with plugins. Feedback from @kdy1 was: > I think it's a good idea to disable plugin by default for nextpack. We don't use it for most of daily development, but it's very large and slow to compile Tested by running both: ``` pnpm build-native pnpm build-native-no-plugin ```		2024-05-30 17:03:15 -07:00
..
crates	next-swc-napi: Remove "plugin" from default feature list (#66380 )	2024-05-30 17:03:15 -07:00
native	Extract next-swc Rust code into its own package (#31635 )	2021-11-21 12:59:56 +01:00
package.json	next-swc-napi: Remove "plugin" from default feature list (#66380 )	2024-05-30 17:03:15 -07:00
README.md	chore: fix some typos (#64276 )	2024-04-10 04:04:52 +00:00
turbo.json	next-swc-napi: Enable "plugin" feature by default (#66006 )	2024-05-22 11:09:04 -07:00

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 (implementing CustomTransformer) lives, which wraps swc's transformer in the next-custom-transforms.
next-api: Binding interface to the next.js provides a proper next.js functionality using next-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 use VisitMut instead of Fold for the performance reasons.
Implements a new CustomTransformer under packages/next-swc/crates/next-core/src/next_shared/transforms to make Turbopack's ecma transform plugin, then adjust corresponding rules in packages/next-swc/crates/next-core/src/(next_client|next_server)/context.rs.