## Summary
- upgrade `@rspack/core` to `2.0.0-rc.0`
- sync the in-tree next rspack Rust binding/toolchain with newer rspack
releases
- align Next server runtime selection so `NEXT_RSPACK` uses the
turbo-like app runtime path
- include missing compiled `@next/react-refresh-utils` output in
`ncc-compiled`
## What is done
- `@next/rspack` Rust binding builds locally
- `packages/next` builds locally
- rspack-related tests are running and have been reduced to deeper
runtime compatibility failures
## Rspack test investigation
Latest checked CI run: `build-and-test` run `27129243230` at head
`484e7bf1b30655a9f94d0855b9e00774b4b38cd0`.
Confirmed Rspack / webpack parity gaps:
-
`test/e2e/edge-runtime-configurable-guards/edge-runtime-configurable-guards.test.ts`:
Rspack does not expose the webpack parser hooks used by
`MiddlewarePlugin`. The current Rspack path falls back to SWC analysis
in `finishModules`, which can report diagnostics but cannot apply the
parser-time transforms that wrap `eval` / `new Function`, track
`InnerGraph` usage for used vs unused dynamic code, or apply
`unstable_allowDynamic` with webpack parity. Dev therefore misses the
expected dynamic-code runtime warnings and also reports false
`process.cwd` Edge warnings from Next internals; prod fails
allowed/unused dynamic-code cases.
-
`test/development/middleware-overrides-node.js-api/middleware-overrides-node.js-api.test.ts`:
same parser-hook limitation. Webpack can observe that `process.cwd` is
overwritten before use, while the Rspack SWC fallback statically flags
`process.cwd` as an unsupported Edge Node API.
- `test/production/css-features/css-compilation.test.ts`: the CSS is
minified and prefixed as expected, but the Rspack lightningcss path
currently does not expose/control source map generation the way this
test expects, so emitted CSS has no `sourceMappingURL` comment or `.map`
file to assert.
- `test/e2e/app-dir/server-source-maps/server-source-maps.test.ts`:
invalid source maps are not handled with the same graceful diagnostic as
webpack/Node source-map handling. Rspack logs the raw `webpack-internal`
frame for the damaged map case instead of surfacing the expected
`Invalid source map. Only conformant source maps...` message with the
cause.
-
`test/e2e/app-dir/parallel-routes-revalidation/parallel-routes-revalidation.test.ts`:
raw CI output observed a dev-mode timeout waiting for `networkidle`
after refresh/back/forward lazy fetching. This was not the final
structured failure in the latest run, but it remains a Rspack dev parity
follow-up around router cache lazy fetches and network settling.
- `test/e2e/middleware-src/middleware-src.test.ts`: after the test adds
root middleware files, Rspack dev still lets `src/middleware`
participate; the expected behavior is that only the root middleware
runs.
- `test/e2e/env-config/env-config.test.ts`: changing `.env` logs `Reload
env:` but the client keeps the previous `NEXT_PUBLIC_` value, pointing
at an Rspack dev env invalidation/HMR gap.
-
`test/e2e/app-dir/use-cache-without-experimental-flag/use-cache-without-experimental-flag.test.ts`:
after enabling the `useCache` flag, the dev server does not finish
restarting, pointing at build-error recovery/restart parity.
-
`test/development/app-dir/server-navigation-error/server-navigation-error.test.ts`:
middleware navigation-error cases hit `ERR_CONNECTION_REFUSED`,
consistent with the Rspack dev server exiting or restarting unexpectedly
during those error flows.
- `test/e2e/opentelemetry/instrumentation/opentelemetry.test.ts`: the
custom-server dev process exits before the SDK handle is initialized,
then cleanup fails on `shutdown`; this needs follow-up in Rspack
dev/custom-server startup.
- `test/e2e/next-image-new/app-dir/app-dir.test.ts`: after toggling
image source, `onLoadingComplete` still reports the previous image
dimensions/source, pointing at an Rspack dev image/HMR or asset
invalidation parity issue.
- `test/e2e/node-cli-args/node-cli-args.test.ts`: on Node `20.19.x`,
`node --experimental-network-inspection` resolves instead of rejecting.
This looks like a Node-version behavior change rather than an Rspack
compiler issue.
Not attributed to this Rspack upgrade:
-
`test/e2e/app-dir/instant-navigation-testing-api/instant-navigation-testing-api.test.ts`
was marked by `scripts/pr-status.js` as a known flaky test across
branches.
-
`test/production/app-dir/build-output-prerender/build-output-prerender.test.ts`
ran in the webpack prod job and only differs by prerender error ordering
in the inline snapshot.
<!-- NEXT_JS_LLM_PR -->
---------
Co-authored-by: Benjamin Woodruff <[email protected]>
Rspack now enables persistent caching by default.
## Performance Comparison
### Pages Router
I benchmarked performance using this repo:
https://github.com/SyMind/chakra-ui-docs/tree/next-rspack to test the
Next.js pages router.
I tested the performance with the following steps:
1. Execute `pnpm run dev`
2. Wait for the server to be ready (indicated by the 'Ready' message)
3. Run curl on the root endpoint (/)
Each build was run 5 times, and the shortest time to reach "Compiled
successfully" was recorded.
Test environment: Apple M1 Pro CPU
| Tool | Build without cache | Build with cache | Dev without cache |
Dev with cache |
|-------------|---------------------|------------------|---------------------------------|----------------|
| Rspack | 3.8s | 2.6s | 1.7s | 3ms |
| Webpack | 14.0s | 4.0s | 7.8s | 3.2s |
### App Router
I benchmarked performance using this repo:
https://github.com/SyMind/shadcn-ui/tree/next-rspack to test the Next.js
app router.
I tested the performance with the following steps:
1. Execute `pnpm run dev` or `pnpm run build`
2. Wait for the server to be ready (indicated by the 'Ready' message)
3. Run curl on the root endpoint (/)
Each build was run 5 times, and the shortest time to reach "Compiled
successfully" was recorded.
Test environment: Apple M1 Pro CPU
| Bundler | Build (No Cache) | Build (Cache) | Dev (No Cache) | Dev
(Cache) |
|------------|----------------------|-------------------|--------------------|-----------------|
| Rspack | 12.3s | 5.9s | 7.1s | 1941ms |
| Webpack | 27.0s | 13.0s | 11s | 9.6s |
## About Rspack Persistent Cache Strategy
> packages/next/src/server/dev/hot-reloader-rspack.ts
Rspack's persistent caching differs from Webpack in how it manages
module graphs. While Webpack incrementally updates modules, Rspack
operates on complete module graph snapshots for cache restoration.
Problem:
- Next.js dev server starts with no page modules in the initial entry
points
- When Rspack restores from persistent cache, it finds no modules and
purges the entire module graph
- Later page requests find no cached module information, preventing
cache reuse
Solution:
- Track successfully built page entries after each compilation
- Restore these entries on dev server restart to maintain module graph
continuity
- This ensures previously compiled pages can leverage persistent cache
for faster builds
## Note
I have updated the test case configuration in
`test/integration/telemetry/next.config.use-cache` to disable persistent
cache.
This is because, whether using webpack or Rspack, when persistent
caching is enabled, modules are no longer recompiled by loaders, which
prevents the Telemetry plugin from collecting information.
Please note that this issue also exists with webpack. You can reproduce
it locally by running `pnpm run test
test/integration/telemetry/test/config.test.js` twice.
update @next/rspack-core version to 1.0.2 and update the snapshot
other changes:
- packages/next/src/build/webpack-config.ts
Adjusted configuration to account for differences in default node config
between Rspack and Webpack.
- packages/next/src/shared/lib/format-webpack-messages.ts
Added a fallback to moduleIdentifier in cases where Rspack does not
correctly populate moduleName.
1. Fixed the incremental update bug in buildChunkGraph.
2. Fixed a bug in Rspack's built-in CssChunkingPlugin.
For detailed release information, please see
https://github.com/web-infra-dev/rspack/releases.
Note: All the faulty Rspack test cases on GitHub, from what I can see,
either time out or also produce errors in Rspack version 1.5.0.
---------
Co-authored-by: Benjamin Woodruff <[email protected]>
1. Fixed the incremental update bug in buildChunkGraph.
2. Fixed a bug in Rspack's built-in CssChunkingPlugin.
For detailed release information, please see https://github.com/web-infra-dev/rspack/releases.
TODO: Rspack currently does not support the hooks and chunk methods
required by `ForceCompleteRuntimePlugin`.
Temporarily disable `ForceCompleteRuntimePlugin` when using Rspack as
the bundler.
This plugin ensures complete webpack runtime is available during soft
navigation to prevent runtime function errors, but Rspack currently does
not support the required compilation hooks and chunk graph APIs.
Co-authored-by: Will Binns-Smith <[email protected]>
Use `@next/rspack-core` to replace `@rspack/core` in order to utilize the extended `NextExternalsPlugin` plugin.
The purpose is to enhance Rspack's performance in Next.js.
1. Added functionality to change the package name in the rspack release
CI.
2. Fixed a bug in the get_resolve method of the NextExternalsPlugin.
3. Prepared the @next/rspack-core for the 1.0.0 version release.
Added a new `rspack` directory as an independent Rust and pnpm
workspace, dedicated to building Next.js Rspack bindings. It shares code
with Turbopack through the `next-taskless` crate.
This commit addresses the bugs where Hot Module Replacement (HMR) was
not functioning correctly in Rspack mode. Component edits would often
result in no update or a full page reload instead of a fast,
state-preserving refresh.
This commit implements a new, custom React Refresh plugin and runtime
specifically for Rspack, which correctly orchestrates the HMR lifecycle.
In the rspack-1.5.0 rc.0 release, many NAPI-side optimizations have been
added, reducing the build time for app router projects from 20.0s to
15.0s.
## Note
I benchmarked performance using this repo:
https://github.com/SyMind/chakra-ui-docs/tree/next-rspack to test the
Next.js app router.
I tested the performance with the following steps:
1. Execute pnpm run dev or pnpm run build
2. Wait for the server to be ready (indicated by the 'Ready' message)
3. Run curl on the root endpoint (/)
4. Each build was run 5 times, and the shortest time to reach "Compiled
successfully" was recorded.
Test environment: Apple M1 Pro CPU
During JavaScript profiling, I identified repeated calls to the exclude
function in the webpack configuration and implemented caching to
optimize it.
<img width="2248" height="772" alt="image"
src="https://github.com/user-attachments/assets/1fdb03f3-2904-4195-a538-7b1f4646f0f2"
/>
I tested the performance using the
[chakra-ui-docs](https://github.com/SyMind/chakra-ui-docs) repository
with the following steps:
1. Execute `pnpm run dev`
2. Wait for the server to be ready (indicated by the 'Ready' message)
3. Run `curl` on the root endpoint (`/`)
| | Webpack | Rspack |
|-|-|-|
|After| Compiled / in 8.3s (2682 modules) | Compiled / in 2.3s (2650
modules) |
|Before| Compiled / in 7.8s (2682 modules) | Compiled / in 1983ms (2650
modules) |
---------
Co-authored-by: Benjamin Woodruff <[email protected]>
<!-- 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 #
-->
update Rspack to 1.4.2, in this version we fix bugs when using Rspack
persistent cache in next.js.
Now user can try Rspack persistent cache by follow way:
```js
const config = {
webpack: (config) => {
config.experiments.cache = {
type: 'persistent'
};
return config;
},
};
```
Rspack's decision to avoid parser hooks, I propose discussing
alternative approaches to implement code analysis in middleware plugins.
A alternative code analysis approach. During the `finishModules` phase,
implement a custom warnForEdgeRuntime method via N-API to perform
module-level code analysis.
Passes tests:
1. test/integration/edge-runtime-module-errors/test/module-imports.test.js
2. test/integration/edge-runtime-with-node.js-apis/test/index.test.ts
Rspack's incremental build algorithm causes a situation where deleted
entries in dynamic entries still get built.
If a page is deleted, an infinite loop occurs in the corresponding
`next-app-loader`, causing the entire compilation to hang.
The root cause of the hang lies in `const resolvedPagePath = await
resolver(matchedPagePath)` failing to resolve `resolvedPagePath`,
preventing the loop from exiting.
When `resolvedPagePath` doesn't exist, we should immediately throw an
Error. This logic would also benefit webpack, as scenarios where pages
are deleted during the execution of `next-app-loader` do occur.
Rspack currently lacks support for `loadModule` in loader contexts.
As an alternative solution, we can using native fn implemented by us
using SWC to replace load module.
---------
Co-authored-by: Benjamin Woodruff <[email protected]>
Rspack support config.experimental.useLightningcss to switch
css-minimizer-plugin.
Rspack using LightningCssMinimizerRspackPlugin by default.
If users encounter some CSS issues, they can switch back to the
css-minimizer-plugin through `config.experimental.useLightningcss:
false`.
In test mode, Rspack uses css-minimizer-plugin for compatibility.
update build output snapshots in following test cases for Rspack.
-
test/e2e/app-dir/use-cache-segment-configs/use-cache-segment-configs.test.ts
-
test/e2e/app-dir/use-cache-unknown-cache-kind/use-cache-unknown-cache-kind.test.ts
-
test/e2e/app-dir/use-cache-without-experimental-flag/use-cache-without-experimental-flag.test.ts
- test/integration/css-minify/test/index.test.js
Use rspack.EvalSourceMapDevToolPlugin when running with Rspack
The modification specifically pass the test case in:
test/integration/server-side-dev-errors/test/index.test.js
Upgrade Rspack to version 1.3.11
This update includes several important improvements and new features:
1. Runtime source map generation
- Pass test cases:
test/production/generate-middleware-source-maps/index.test.ts
2. JS API now provides access to buildInfo.assets
- Pass test cases: test/e2e/app-dir/next-font/next-font.test.ts
3. Full options support for EvalSourceMapDevToolPlugin
4. New built-in CssChunkingPlugin implementation
- Pass test cases: test/e2e/app-dir/css-order/css-order.test.ts
- test dev `test/e2e/app-dir/dynamic-data/dynamic-data.test.ts`
Test fails due to Rspack's lack of support for
`compilation.codeGenerationResults` JS API.
Next.js skips resolving `.d.ts` files. Rspack can achieve the same
behavior by adding the `resolve.restrictions: [/^(?!.*\.d\.ts$).*$/]`
configuration.
Following test cases will be passed:
- test/integration/typescript-paths/test/index.test.js
- typescript paths default behavior should not resolve to .d.ts files
- typescript paths without baseurl default behavior should not resolve
to .d.ts files
-
test/integration/typescript-workspaces-paths/packages/www/test/index.test.js
- TypeScript Features default behavior should not resolve to .d.ts files
<!-- 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 #
-->
The PR has resolved the failures in
`test/integration/create-next-app/templates/*.test.js`.
The `create-next-app` CLI now supports a `--rspack` flag to initialize
projects with Rspack.
Test cases in `test/integration/create-next-app/templates/*.test.js`
have been updated to conditionally use `--rspack` based on
`process.env.NEXT_RSPACK`.
---------
Co-authored-by: JJ Kasper <[email protected]>
<!-- 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 #
-->
The PR has resolved the failures in
`test/integration/cli/test/index.test.js`.
1. Prevent next Rspack experimental warning during test runs when
`process.env.__NEXT_TEST_MODE` is set
2. Updated assertion to expect `next-rspack` version string when using
Rspack
---------
Co-authored-by: JJ Kasper <[email protected]>
The Yarn PnP test suite (`test/e2e/yarn-pnp/test/*.test.ts`) fails when
running with Rspack because tests don't install required `@rspack/core`
dependency.
<!-- 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 #
-->
let Rspack to pass the test cases it was previously able to pass.
1. update Rspack to 1.3.9
2. Moves `moduleSpansByCompilation` setting in `RspackProfilingPlugin`
from the `compilation` hook to `thisCompilation`.
`TraceEntryPointsPlugin` relies on `moduleSpansByCompilation` during its
`thisCompilation` hook. Since the `compilation` hook triggers before
`thisCompilation`, initializing the map earlier leads to:
```
Error: × TypeError: Cannot read properties of undefined (reading
'traceChild')
```
relate: https://github.com/vercel/next.js/pull/78011
3. The test case
`test/integration/middleware-prefetch/tests/index.test.js` was failing
due to an unreliable asset name matching strategy.
Asset names follow the pattern:
`static/chunks/pages/[pagename]-[hash].js`.
Test was checking for `ssg-page-2-[hash].js` by looking for names
starting with `ssg-page-2`.
This could produce false positives when `ssg-page-[hash].js` happens to
have a hash starting with `2`.
4. test dev `test/e2e/app-dir/dynamic-data/dynamic-data.test.ts`
Test fails due to Rspack's lack of support for
compilation.codeGenerationResults JS API.
5. test dev `test/e2e/app-dir/dynamic-href/dynamic-href.test.ts`
Same compatibility issue as above.
6. test dev `test/development/acceptance-app/hydration-error.test.ts`
Same compatibility issue as above.
6. test dev `test/development/app-dir/ssr-in-rsc/ssr-in-rsc.test.ts`
Test fails due to differing error message formats between
implementations.
