<!--
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 that you're making:
-->
Partial solutions for WEB-225.
One of the issue we want to improve is version bump process across
multiple dependencies sharing same transitive dependencies. There were
known cases of last-minute build failures of next-swc due to this. The
biggest thing is we have lot of dependenceis rely on swc_core, and
consolidating it altogether is tricky.
PR introduces `next-binding`, which reexports all the related
dependencies that next-swc and turbopack commonly uses. Unfortunately,
this is not a complete solution, but at least it'll make `upfront` cost
to turbopack when it try to update swc_core and others, so by the time
upgrading it in next-swc we expect minimal friction. Note not 0
friction: due to how cargo behaves for the merging all of the features,
there's still chances to have some build failures but meaningfully less
I believe.
I think the easiest way to describe before / after is having some
diagrams. This is rather simplified to illustrate problems easily, i.e
when it comes to actual build if there are same version of deps cargo
will dedupe, so below illustaration only would occur for non-compatible
version cases, etcs.
**Before**
```mermaid
graph TD
A[next-swc] --> B(next-dev)
A --> C(swc_core)
A --> D(swc_emotion)
D --> E(swc_core)
A --> F(styled_jsx)
F --> E
A --> G(mdxrs)
G --> H(swc_core)
B --> I(swc_core)
B --> J(swc_emotion)
J --> K(swc_core)
```
**After**
```mermaid
graph TD
A[next-swc] --> B(next-binding)
B --> C[swc_core]
B --> D[swc_emotion]
D --> I[swc_core]
B --> H[styled_jsx]
B --> F[next-dev]
B --> J[node-file-trace]
F --> C
H --> I
B --> E(mdxrs)
E --> G(swc_core)
```
You can see repeated dependencies (`swc_core`, `swc_emotion`) occurs lot more in next-swc in `before`, including next-swc top level direct import itself. In result, update process have to align between next-swc, turbopack, swc-plugins and others.
With newly proposed changes, `next-swc` no longer directly owns deps reduces those repetaed deps. At the moment of version bump, only `next-binding` need to be updated.
This brings small caveat however : next-swc does not directly update `swc_core`, but have to bump turbopack and its transitive dependencies. Given our bump process usually requires to bump up turbopack anyway, I wouldn't consider this as hard blocking though.
<!--
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 that you're making:
-->
## Bug
Fixes WEB-166.
This supersedes https://github.com/vercel/next.js/pull/43449, updating
swc_core and turbopack both with its transitive dependencies. Version
bump includes one important build side issues to having circular
dependencies.
<!--
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 that you're making:
-->
This PR implements a configuration option in `next.config.js` to support
for rust-based MDX compiler (https://github.com/wooorm/mdxjs-rs).
Currently it is marked as experimental, as mdx-rs and loader both may
need some iteration to fix regressions.
When a new experimental flag is set (`mdxRs: true`), instead of using
`@mdx/js` loader `next/mdx` loads a new webpack loader instead.
Internally, it mostly mimics mdx/js's loader behavior, however actual
compilation will be delegated into next/swc's binding to call mdx-rs's
compiler instead.
I choose to use next-swc to expose its binding function, as mdx-rs
internally uses swc already and creating new binary can double up
bytesize (with all the complex processes of publishing new package).
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see `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`
- [ ] Integration 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`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
<!--
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 that you're making:
-->
This PR utilizes cargo's new feature from latest release (1.64.0),
inheriting dependency from a workspace.
In short, top-level workspace cargo manifest can specify a version of
dependency to use, then actual packages uses it without re-declaring
version per each via workspace = true. This will help to dedupe
different versions of packages, also potentially avoid conflicts if
forgot to bump up specific versions.
In this pr only touches swc_core, which is a base dependency we use in
several place. One another benefit for this is bump up PR can be lot
more simplified, only need to update single Cargo.toml when we bump up.
Note rust-toolchain has updated to use nightly version after 1.64.0 to
enable this.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see `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`
- [ ] Integration 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`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)