Can't select a universal swc_core version for my plugin to satisfy all next.js users

[YassinEldeeb]

Related Issues:

• [NEXT-939] SIGSEGV on next build with 13.2.4 vercel/next.js#46989
• @graphql-codegen/client-preset-swc-plugin ... dotansimha/graphql-code-generator#9450
• @graphql-codegen/client-preset-swc-plugin not working with nextjs ^14 dotansimha/graphql-code-generator#9753
• Plugins built with swc_core >= 0.76.0 doesn't work in the next-swc and @swc/core #7470

Issue Description:

Hey! I'm Yassin, a member of The Guild.

Hey there! I'm Yassin, a member of The Guild. A few months ago, in collaboration with our contributor @JesseVelden, we introduced an SWC plugin for GraphQL Code Generator. The aim was to optimize bundle size for SWC (Next.js) projects.

Initially, it worked really well, but after a few weeks, it started breaking with a very common error:

Error: failed to process failed to invoke plugin: failed to invoke plugin on 'Some("/c/next-app/pages/index.tsx")'

Caused by:
    0: failed to invoke `/c/next-app/node_modules/@graphql-codegen/client-preset-swc-plugin/swc_plugin.wasm` as js transform plugin at /c/next-app/node_modules/@graphql-codegen/client-preset-swc-plugin/swc_plugin.wasm
    1: RuntimeError: out of bounds memory access

Stack backtrace:
   0: _napi_register_module_v1
   ...
   
Import trace for requested module:
./pages/index.tsx

I started digging the root of the issue, I noticed that the Next.js version has a significant impact on the plugin's functionality. Bumping the Next.js version breaks it, while pinning it to a specific version keeps it working.

I recently came across this valuable documentation that sheds light on the issue:
https://swc.rs/docs/plugin/selecting-swc-core

It mentions:

Currently, the Wasm plugins are not backwards compatible. So you need to select an appropriate version of swc_core for your plugin.

From what I understand, this implies that for each swc_core version range (e.g., v0.78.x), the plugin works for a specific range of Next.js versions, which is at the root of the problem.

Questions and Concerns:

1. As a plugin maintainer, how should I determine the appropriate swc_core version?
2. Choosing v0.76.x works for users with Next.js versions ranging from next@v13.4.3-canary.2 to next@v13.4.7, but it becomes incompatible with users on more up-to-date versions of Next.js. How can we address this?
3. Bumping the swc_core version to the latest, like v0.82.x, makes it compatible with newer Next.js versions but breaks compatibility with older versions. How can we ensure a smoother transition for users as they upgrade Next.js?

My Initial Approach:

I explored creating an installation CLI. It would read the Next.js version in a project's package.json and determine the right SWC plugin version to use. When publishing from our end, the SWC plugin would provide versions like:

• @graphql-codegen/swc-plugin@v0.78.x
• @graphql-codegen/swc-plugin@v0.76.x
• @graphql-codegen/swc-plugin@v0.75.x

The CLI would decide on the installation version based on the read Next.js version from the project. However, upgrading the Next.js version would break the SWC plugin.

Challenges:

• Keeping up with the frequent releases of SWC Core and Next.js versions is challenging.
• One idea might be to automate some build and publishing steps based on scraping their documentation, but there's no guarantee it'll always be updated promptly, nor that the UI will be persistent for the scraper.

Of course, the above is a very frugal solution, and not very practical. So, I abandoned that route.

Proposed Solution:

To ensure that all Next.js users can successfully use the SWC Client Preset plugin (and other SWC plugins, I have seen many complain about the same issue), we need to find a way to handle the version compatibility issue effectively. This could involve better documentation, tooling, or strategies for selecting the appropriate swc_core version based on the Next.js version in use.

I might be missing a crucial detail in handling maintaining it, please correct me if I'm wrong.

Let's discuss on finding a solution that works for all users and avoids compatibility issues.
I would really appreciate your insights and suggestions! 🙏

Minimal reproduction:

You can checkout to both of those branches and follow the README instructions, the only difference between them is:

git diff swc_core_0.75_next-13.5.4 swc_core_0.75_next-13.3.0
-    "next": "13.5.4",
+    "next": "13.3.1",

• https://github.com/YassinEldeeb/swc_core_nextjs_incompatibility_mre/tree/swc_core_0.75_next-13.5.4
• https://github.com/YassinEldeeb/swc_core_nextjs_incompatibility_mre/tree/swc_core_0.75_next-13.3.0

The above uses the SWC Client Preset plugin which is compiled with swc_core@0.75.x.

You will notice that with different Next.js versions, it can break.

Expected behavior

SWC Plugins should work with all Next.js versions with no hassle.

Actual behavior

SWC Plugins break depending on the Next.js versions and the swc_core version which conflicts.

Version

All

Additional context

No response

[kwonoj]

SWC Plugins should work with all Next.js versions

In short, this is impossible. The issue you created is an umbrella issue for the swc plugin stablization, one of the large reason plugin support is marked as beta.

Since there is inevitable breaking changes for the AST struct, each time it happens plugin have to align swc_core version to the host runtime. What we are trying to achieve is however, 1. reduce the frequency of breaking changes 2. provide a better diagnostics for the runtime / plugin mismatch 3. provide some sort of interfaces to handshake in runtime instead of panic

There are tracking issues for these kinds of problems:

• Deserialize plugin's serialized bytes with bytechecked #7461
• SWC_CORE semver complaint stablization  #5745
• AST struct version bump process documentation #5267
• Wasm plugins are not backward compatible #5060

[kwonoj]

I'd suggest closing this issue since we have tracking actionable items already, just blocked by some upstream support / internal blockers need to be resolved.

[swc-bot]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.