build(cargo): setup next-binding package

[kwonoj]

Related with WEB-225.

This is not a complete solution, more close to stop-gap instead. As shared before, if I want to bump up swc_core to certain version without dupe (i.e, if there are breaking changes we should bump altogether) it need couple of steps

• Update swc_core in swc-plugins, publish new plugin crates
• Update swc_core and plugins (emotion, etcs) in turbopack
• Update swc_core in mdxjs-rs , wait for new version publish
• Finally, in next-swc, update swc_core, swc-plugins, mdxjs-rs, lastly turbopack

Not only these steps are verbose, also requires to move lot of parts in different repo altogether.

We can't cleanly resolve transitive dependencies version between turbopack & plugin + others, but at least we can control direct dependencies version between next-swc and turbopack (swc_core, plugins, etcs).

next-binding package is equivalent to swc_core to next-swc, let it reexports all the necessary features to next-swc to have single known version of dependencies live between those two.

With this approach, we'll have roughly these kind of dependency relations:

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)

We still have to deal with swc_core versions across, but simplifies other things compare to today.

PR currently sets up barebone only. I'll work on reexporting things gradually.

[vercel]

@kwonoj is attempting to deploy a commit to the Vercel Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated
examples-kitchensink-blog	🔄 Building (Inspect)		Nov 28, 2022 at 5:06PM (UTC)
examples-nonmonorepo	🔄 Building (Inspect)		Nov 28, 2022 at 5:06PM (UTC)
examples-svelte-web	🔄 Building (Inspect)		Nov 28, 2022 at 5:06PM (UTC)

3 Ignored Deployments

Name	Status	Preview	Updated
examples-basic-web	⬜️ Ignored (Inspect)		Nov 28, 2022 at 5:06PM (UTC)
examples-designsystem-docs	⬜️ Ignored (Inspect)		Nov 28, 2022 at 5:06PM (UTC)
examples-native-web	⬜️ Ignored (Inspect)		Nov 28, 2022 at 5:06PM (UTC)

[kwonoj]

This PR is now ready for review to try with next-swc.

[ForsakenHarmony]

why are these prefixed with __?

[kwonoj]

To indicate this is not a public feature. This is a convention we used in upstream swc as well, similar to old javascript var naming to indicate it is not a public interface user can expect to use.

[ForsakenHarmony]

But the whole package is not public, so this is just noise 🤷

[kwonoj]

Yes true, but also technically next-swc is a consumer (in terms of visibility, not corp-wise relations) and this could be a sort of indication what's what. At least, these are literally internal features so we can change anytime if we don't feel this is not needed.

[sokra]

Maybe move this into the rust_lint step to avoid blocking starting the tests longer than needed

[kwonoj]

This rust_prepare step is where we ran cargo check already, so I think it's natural fit to chain further --features based check especially this'll allow to reuse rust cache built from previous cargo check. We can measure these times later and trying to optimize further.