[Meta] collecting feedback for new transform plugin interface

[kwonoj]

New transform plugin is ready to try out 🎉

(Previous references: #2929)

What is this?

SWC currently has an interface to support plugins written in javascript for its transform (https://swc.rs/docs/usage/plugins). However, it was not strongly recommended due to several ergonomics, including performance bottleneck. Since then, SWC has tried to attempt to implement new plugin system does work on the host side (SWC's rust binary). #3167 was created to track initial effort for the experiments, and we think we have reached the state where people can try to write a plugin with new interfaces.

It is marked as experimental currently as we expect we'll have to iterate few changes or fixes we couldn't find while working on this feature. This discussion is to collect feedback, suggestions, or compile list of bugs to be fixed to stablize new plugin system.

How to write a plugin

The new plugin system uses WebAssembly-based runtime. Currently, there is a rust-based package to support this (https://crates.io/crates/swc_plugin) which includes utilities to write plugins more easily. Package swc_cli includes small commandline utility to help creating a new project. First, if you haven't install swc_cli package, install it via cargo. It'll allow to use commandline tool swc. (note binary name is swc, while package name is swc_cli)

cargo install swc_cli

Then you can create new plugin project.

swc plugin new ${plugin_name} --target-type=wasm32-wasi

One thing to note is you should specify --target-type between wasm32-wasi or wasm32-unknown-unknown. SWC's transform plugin should be either type of WebAssembly binary. Major difference between those 2 target is wasi support. If you're not sure what to use, or you'd like to use macros like println!(), choose wasi.

Once a project is created you can write actual transform visitor! It can be done by implementing proper visit_mut_* interfaces for your visitor. While there is no dedicated documentation yet, you can refer to some of core transform implementations as examples. Test cases like this or core's jest support can be a good reference to look into.

To load plugins, you may use swcrc's jsc.experimental configs:

{
  jsc: {
    ...
   experimental: {
     ...
     cache_root: String // optional, specify where swc will create wasm bytecode cache
    // list of plugins. If `pluginname` is resolvable to npm package, it'll try to load from installed npm packages.
    // or it can be an absolute path to the .wasm binary
     plugins: [ ['pluginname', pluginOptions: Record<string, any>] ] 
   }
}

Please give it a try, and share feedbacks! 🙏 We'd like to iterate as much before making this as stable release.

If you found bugs, or something is not working: Please create an issue at https://github.com/swc-project/swc/issues with reproducible repo
If you have opinions, suggestions: Feel free to use comment in here. Please use thread for each discussions as possible.

FAQ

1. Plugin binary is WebAssembly. Does that mean I can write a plugin using other than rust?

Technically, it is correct. As long as you can generate WebAssembly binary satisfies SWC's transform interface, it'll work. However, there are some tricky challenges to making it actually work, such as:

• Serialization / Deserialization: There is no other language binding for the serialization / deserialization mechanism used in plugin.
• AST interfaces: We only have typed ast interface support in rustlang so far
• Utility support: Same as AST, swc's AST helper is written in rustlang.

If anyone can attempt this and making it work it'd be great!

2. I'm using wasm version of SWC. How does plugin work?

Currently, wasm version of SWC doesn't support any plugin including javascript one as well.

(Updated Mar / 9 / 2022) : Refer #3934.

3. What'll happen to javascript plugin support?

First, It won't be deprecated in a day or two. If you have existing javascript plugins for the SWC, it'll work.
However there are known blockers for the javascript based plugins - notably performance - which blocks us to improve it further. This is the main reason new plugin interface has been implemented. I'm planning to post separate RFC for the migration plan for this - at this moment, I expect eventually javascript plugin will be considered as legacy.

Known issues / discussions.

1. How to deal with possible breaking changes in AST

This is by far the biggest blocker for the stabilization of plugin interface. SWC chooses to expose AST directly to the plugin. This enables a lot of good things, but also AST becomes a part of the plugin interface contract. If swc/core changes AST - adding, removing, modifying types of AST - it'll be major breaking changes require plugin to be updated to follow those.

One positive thing is inevitable breaking change (removing, modifying AST) does not happen frequently. We expect to add some more types somewhat more frequently than those. There is upstream issue filed for supporting it (rkyv/rkyv#164) and if we have those upstream support, it'll be relatively easy to make AST as stable interface contract.

2. Plugin transform interface

Currently, plugin's main transform interface is defined as

fn process(program: Program, _plugin_config: String, _context: String) -> Program;

which passes AST and each plugin's config (not the whole swcrc!). It may sufficient or not and we'd like to hear for opinions.

3. Config interface

It is unclear whether the current swcrc config interface is good enough. In particular, current config is slightly polymorphic by using the first tuple value as either package name or absolute path which can be confusing.

#3247 also tracks resolving support.

4. Plugin scaffolding package.json support ✅

Filed - #3548

5. plugin config module resolving issue ✅

This is different to #3247 - make existing resolver works out of the box with wasm plugin when package.json sets proper main entrypoint. Currently swc trying to resolve its optionaldependencies.

6. Additional context for the plugin ✅

Now plugin's transform entrypoint fn accepts 3rd param context: String.
This is a stringified JSON for Record<string, unknown> type can contain arbitrary informations.

Others

[RiESAEX]

1. for command swc plugin new, Compared to the current behavior, I prefer not to create a directory and infer the plugin name from the pwd, as cargo init does.
2. I think we can generate a default test case for visitor (with test! or test_transform in swc_ecma_transforms_testing)
3. should it generate a default package.json for plugin publish?

[williamtetlow]

I think it makes sense to do 3 too

[kwonoj]

1. I don't have strong opinion. We may able to add init subcommand for those if there are people in favor of those. Either case it should be trivial (and non-major breaking) for the cli.

2. I agree, but not sure what'd be good default test case. Thoughts?

3. Yes, agree. Plugin template scaffold generates package.json for easier publish #3548

[RiESAEX]

like

test!(
    ::swc_ecma_parser::Syntax::default(),
    |_| as_folder(TransformVisitor),
    testname,
    r#"console.log("hello world")"#,
    r#"console.log("hello world")"#
);

Just want to show a starting point for those who want to write tests but don't know how.

[williamtetlow]

I think we should add a basic README too if we are adding tests and a package.json for how to build, run tests and publish.

[williamtetlow]

Is it possible to get the name of the file being processed inside the plugin?

[esamattis]

Filename / path based conventions. For example in Next.js exported getInitialProps() has a special transform when under the pages dir.

[williamtetlow]

My use case was creating transformer that prefixes console.logs with filename and line number but as esamattis said I've seen it used as context for Babel transformers before.

[AlexandrHoroshih]

We have a similiar usecase for filename and path with effector (multi-store state manager) - it is used in effector/babel-plugin to provide various debug information for tools like effector-inspector

Also knowing file and path inside plugin is necessary to generate stable ids for every store - it is needed to correctly transfer state of the stores to the client during SSR

[kwonoj]

#3568 supports providing arbitrary information to the plugin's transform. Currently it only contains file path, only if given transform contains actual file path.

[kdy1]

If you use newer version of @swc/core and swc_plugin, you will be able to use filename.
(I cut off a release because of this)

[williamtetlow]

Created this plugin, repo has examples and tests too https://github.com/williamtetlow/swc-plugin-console-prefix

Do you have an example package.json for a plugin? Do we only need to include wasm file and no JS?

[RiESAEX]

if my memory is correct,
current npm module resolver is for the native plugin(the structure looks like packages for @swc/core, a mian package with several optiondependence for different platform) .
I didn't mention this because there was #3247...

[kwonoj]

yes, #3247 is listed in main thread and at least it should honor normal npm package resolving to read its main property directly.

[kwonoj]

#3548 tracks this.

[kwonoj]

#3566 resolves this by 1. swc plugin new will create package.json 2. @swc/core' now resolves plugin from package if plugin name is specified as npm packages. (or can use absolute path still).

[williamtetlow]

What do you think of saying to add wasm target when building instead of setting default in .cargo/config?

cargo build --release --target=wasm32-wasi

I feel like the common dev flow is going to be more TDD based with users writing tests to assert the output when creating the Visitor and building wasm and running it with swc will be done less frequently.

I think it will be common to add dev-dependencies that don't support wasm target. For example, I'm installing swc with plugin feature in dev-deps so I can run an example and wasmer-vfs sub dependency doesn't support the target.

It's easier for me to run unit tests like cargo test -- and only specify target on cargo build as I build wasm binary a lot less often than I run tests.

[kwonoj]

I'm on the fence for this. First, I started off from a manual target and then settled down with the current approach. After all, this is a scaffolding anyone can modify while I wanted to provide the smallest out-of-the-box working example from template instead of running cargo build emits a bunch of compilation error and have to find out it requires manual target setting.

also having default target helps to generate set of files, such as package.json to have correct main property to the entrypoint binary. If ppl needs manual control and aware how to do those, either they can adjust created project or create new one manually maybe?

[williamtetlow]

Hmm ye good point. Personally I like building for current machine target by default and then customizing with manual target setting but if we are going to introduce package.json and such we should probably set target when we scaffold 😄

[Drevoed]

Is it possible to opt out of default compilation pipeline for plugins? Or maybe add a preprocess step. Use case is being able to perform JSX transforms on preserved AST without SWC compiling it to react JSX calls.

[kwonoj]

I'm not sure if I understood this correctly: are you saying only runs transforms for the plugin and do not run any other transforms after by swc core itself?

[Drevoed]

Yes. That would be a great feature.

[Drevoed]

As was said already in discord discussion - JSX is not only react.

[kwonoj]

First, this request is not actually plugin - it is controlling @swc/core's transform behavior. I'd like to limit this discussion for the plugin itself only.

Also pasting my opinion in discord for reference:

in case of typescript makes sense as it clarifies output to be further consumed by another transform step. In case of swc, we consider swc is terminal transformer does not require additional transformer once swc completes its transform steps. As kdy already said, I'm not sure if it's something we need to consider or at least in a high priority.

Current focus for the stabilizing plugin interface is focus to make necessary changes for the plugin transform features, not changing core swc's transform behavior.

[fxb]

In fact this minimal plugin without any additional custom logic has the same problems for me:

use swc_plugin::{ast::*, plugin_transform};

pub struct Visitor {}

impl VisitMut for Visitor {
    noop_visit_mut_type!();

    fn visit_mut_call_expr(&mut self, _call_expr: &mut CallExpr) {
    }
}

#[plugin_transform]
pub fn process_transform(program: Program, _config: String, _context: String) -> Program {
    program.fold_with(&mut as_folder(Visitor {}))
}

Both introducing slowness and sometimes causing RuntimeError: out of bounds memory access

[kwonoj]

I'm curious instantiating module per each transform input may cause this issue. (Inside of core, not plugin transform level)

[kwonoj]

I spinned #3598, let's discuss separately.

[fxb]

Simplifying it even further to exhibits the same problems:

use swc_plugin::{ast::*, plugin_transform};

#[plugin_transform]
pub fn process_transform(program: Program, _config: String, _context: String) -> Program {
    program
}

It must be that the WASM runtime overhead that hits 4500 times as it needs to instantiate the plugin for each file?

[kwonoj]

that's what I mentioned in #3540 (reply in thread)

[Drevoed]

Is it possible to also pass comments to plugin? Use case would be replacing comments like react transform does.

[kwonoj]

I may wrong but afaik core transform itself doesn't have comments in its node.

[jantimon]

With @__PURE__ you can tell minifiers like esbuild that the function call can be removed if the resulting value isn't used.

Therefore it would be quite helpfull to be able to modify and inject these comments.

[kwonoj]

#4182 is attempt to track this.

[jantimon]

breaking changes in AST

I guess it's totally fine that SWC will introduce breaking changes at some time.
@babel/core is now version 7 so over the years they had to introduce breaking changes.

What would be the best practice to specify in the package.json for which SWC version a plugin is compatible?

[kwonoj]

Having a breaking change itself is not a concern. The main issue in here is it can happen quite frequently than normally expected.

AST struct can be changed in several ways - adding a new AST property, or removing / renaming existing one. Latter two is unavoidable breaking change, but also it usually won't happen lot. We can definitely control those in reasonable release cadances with major breaking changes.

Adding new one is different. It could happen for various reason, such as supporting new ecma syntax. We can't declare breaking changes each time this happens. If more frequent breaking changes occur, ecosystem will easily fragment. So this question is actually bit narrow like how can we make stable interfaces if AST add new properties in its struct? which requires some internal support like add-only schema serialization / deserialization support.

[kwonoj]

Related upstream: rkyv/rkyv#164

[jantimon]

Invalid package.json name

there are some rules for package.json name:

• package name length should be greater than zero.
• all the characters in the package name must be lowercase i.e., no uppercase or mixed case names are allowed.
• package name can consist of hyphens.
• package name must not contain any non-url-safe characters (since name ends up being part of a URL)

What about converting the plugin name to kebab case automatically in the following example?

swc plugin new myDemo --target-type=wasm32-wasi

[joshcartme]

My question kind of relates to 3 from the original post, but doesn't quite fit. When pointing directly to a WASM binary, is there any way to use a relative path? For example let's say at the top level my project is laid out like:

node_modules
src
webpack

within webpack I have:

dev.config.js
prod.config.js
swc-plugins

The configs use swc loader so somewhere in those files I have:

jsc: {
    ...... stuff,
    experimental: {
        plugins: [
            ['/users/josh/development/project/webpack/swc-plugins/targets/plugin.wasm', {}],
            ['/users/josh/development/project/webpack/swc-plugins/targets/plugin2.wasm', {}]
        ]
    }
}

I'd like for that last bit to look something more like:

plugins: [
    ['./webpack/swc-plugins/targets/plugin.wasm', {}],
    ['./webpack/swc-plugins/targets/plugin2.wasm', {}]
]

I can't figure out how to do that though. Is it possible?

[kwonoj]

When pointing directly to a WASM binary, is there any way to use a relative path

Currently, no. ergonomics around resolving plugin is something need more thoughts with better design. Probably for now you'd use path calculation like

path.resolve(__dirname, ...)

or similar.

[kwonoj]

Or, you could publish plugin as npm pkg then use pkg name as resolver instead. That maybe easier for actual deployment.

[joshcartme]

I'll give it a shot, thanks!

edit. path.resolve got me what I need for now, thank you 👍

[jantimon]

@kwonoj is there any way to use js in .swcrc files? what about a .swcrc.js to allow path.resolve or require.resolve?

[kwonoj]

No. Using js or dynamic runtime for config involves larger discussion other than plugin actually - there are native rust cli, wasm (outside of browser runtime. Yes, current wasm doesn't support plugin but this is for config), and potentially others like edge workers without js runtime which cannot use node.js specific runtime context as-is.

We are trying to carefully approach potential solutions, meanwhile config file will remain as deterministic static json-compatible text.

[martindisch]

Having a pretty great time with the plugin system so far, despite how early it is!

I have what may be a dumb question though because I don't have any experience doing this kind of thing. Say I want to transform some string literals to identifiers and then add imports for them.

Original:

foo("bar");

Transformed:

import { bar } from "baz";
foo(bar);

I have seen this done in babel by

1. Collecting the identifiers from within the visitor
2. In a post() step inserting the import declaration at the top level

Is there a way to either

• Do something similar with a second transformation that has access to the result of the first
• Gain access to the root of the AST from my VisitMut implementation so I can just push an identifier into the import declaration at the top when I encounter it during my transformation below

Edit: I'm aware I could probably do it from my "main function" (#[plugin_transform] pub fn process_transform) by running my first visitor over the Program and then modifying the program directly before returning it. But then I can't use the convenient macro from swc_ecma_transforms_testing for testing, since as far as I know this only takes a Fold implementation, which would be my visitor, but that doesn't include the subsequent modification steps I do in the main function.

[williamtetlow]

Could you do something like the following?

    fn visit_mut_module_items(&mut self, stmts: &mut Vec<ModuleItem>) {
        stmts.visit_mut_children_with(self);

        for ident in self.identifiers.into_iter() {
          // prepend to stmts
        }
    }

[martindisch]

Works like a charm and is much easier than expected. Big thanks!

[cdaringe]

Anyone get a deno recipe goin? I found https://github.com/nestdotland/deno_swc, but think the bindings are out of date. Uncertain if there is another module people use.

import { transform } from "https://x.nest.land/[email protected]/mod.ts";

const code = `import * as foo from "https://bar.org/baz";`;
const out = transform(code, {
  filename: "input.js",
  jsc: {
    experimental: {
      plugins: [
        [
          "./src/middlewares/emit/swc_plugin_deno_emit_server_rewrite_imports.wasm",
          {},
        ],
      ],
    },
  },
});
console.log(out);

error: Uncaught (in promise) failed to parse options

Caused by:
    unknown field `experimental`

:)

[kwonoj]

Deno is not officially supported platform from swc's core yet. There are some things need to be solved around native ffi and esm imports. #3097 (reply in thread)

[konicyQWQ]

How to call swc_ecma_transforms::resolver in the wasm plugin? resolver seems that must running on compiler.run(||{...}) or Globals.set, but it seems that wasm plugin can not get compiler.globals. Maybe I can only use swc_common::Globals::new()?

[kwonoj]

Probably q is in which case plugin need to use it. Resolver is not intended to be run inside of the plugins.

[konicyQWQ]

I found in the wasm plugin, ident in AST has already have mark. So maybe don't need to call resolver manually. But what is q?

[kwonoj]

My q was what was the purpose of tryin to use resolver. Probably you won't need it, as you already explained.

[ehaynes99]

[kwonoj]

Your code has nothing to do with swc_core changes. e.left is Box<Expr> type, so you can't assign Ident directly but should create Box to wrap instead.

[ehaynes99]

Oh, ok. I copied it directly from the docs.

https://swc.rs/docs/plugin/ecmascript/getting-started#implementing-a-visitor

So should it instead be?

fn visit_mut_bin_expr(&mut self, e: &mut BinExpr) {
    e.visit_mut_children_with(self);

    if e.op == op!("===") {
        e.left = Box::new(Expr::Ident(Ident::new("kdy1".into(), e.left.span())));
    }
}

[meskill]

What is the current status of the feature?

as I see, plugins are still under experimental flag. I'm insterested is there are any specific plans or terms to mark it as stable and ready to use?

[kdy1]

It's ready to use I think

[kwonoj]

It is our deliberate decision to leave it under experimental, most of the reasons are not feature related but more for internal stablization such as forward-compat AST / trying to ensure host, plugin SDK semver-compliant breaking changes. Featurewise probably one last thing is support plugin inside of @swc/wasm.

Still there may be some rough edges for writing / using plugins and we expect to fix it forward, but our plan is moving plugin into some sort of beta stage instead of experimental.

[lewisl9029]

Hi there! I created a new plugin using swc plugin new --target-type wasm32-wasi transforms as the docs suggested, and tried to run cargo test without any changes.

Ended up getting this error:

transforms % cargo test
   Compiling swc_ecma_utils v0.105.33
   Compiling swc_plugin_proxy v0.22.20
error[E0603]: module `read_returned_result_from_host` is private
  --> /Users/lewis/.cargo/registry/src/github.aaakk.us.kg-1ecc6299db9ec823/swc_plugin_proxy-0.22.20/src/comments/plugin_comments_proxy.rs:13:28
   |
13 | use crate::memory_interop::read_returned_result_from_host;
   |                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ private module
   |
note: the module `read_returned_result_from_host` is defined here
  --> /Users/lewis/.cargo/registry/src/github.aaakk.us.kg-1ecc6299db9ec823/swc_plugin_proxy-0.22.20/src/memory_interop/mod.rs:1:1
   |
1  | mod read_returned_result_from_host;
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0603]: module `read_returned_result_from_host` is private
 --> /Users/lewis/.cargo/registry/src/github.aaakk.us.kg-1ecc6299db9ec823/swc_plugin_proxy-0.22.20/src/metadata/transform_plugin_metadata.rs:9:21
  |
9 |     memory_interop::read_returned_result_from_host, PluginCommentsProxy, PluginSourceMapProxy,
  |                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ private module
  |
note: the module `read_returned_result_from_host` is defined here
 --> /Users/lewis/.cargo/registry/src/github.aaakk.us.kg-1ecc6299db9ec823/swc_plugin_proxy-0.22.20/src/memory_interop/mod.rs:1:1
  |
1 | mod read_returned_result_from_host;
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

For more information about this error, try `rustc --explain E0603`.
error: could not compile `swc_plugin_proxy` due to 2 previous errors
warning: build failed, waiting for other jobs to finish...

Any ideas what's going on?

[kdy1]

cc @kwonoj

[kwonoj]

This seems coming from latest changes. I'll take a look.

[lewisl9029]

I gave this another try earlier in the week and it seems to be fixed, thank you so much!

Though I'm currently running into a slightly trickier issue:

I've been rewriting the babel plugin for setting up React Fast Refresh for apps built using https://reflame.app into a Rust/WASM based swc plugin to take advantage of swc's speed. It involves a transform that results in something like this:

// Code for Reflame's React Refresh implementation, added using custom babel plugin
const $reflamePreviousRefreshReg = self.$RefreshReg$;
const $reflamePreviousRefreshSig = self.$RefreshSig$;

self.$RefreshReg$ = (type, id) => {
  const fullId = "/landing/home_.tsx" + " " + id;
  self.$reflame.reactRefreshRuntime.register(type, fullId);
};

self.$RefreshSig$ = self.$reflame.reactRefreshRuntime.createSignatureFunctionForTransform;

// Code generated by React Refresh's babel plugin
var _s2 = $RefreshSig$(),
    _s3 = $RefreshSig$(),
    _s4 = $RefreshSig$(),
    _s5 = $RefreshSig$(),
    _s6 = $RefreshSig$();

// Original module code
import * as style_ from '/style_.js';
import * as react_ from 'react';
// ...


// More code generated by React Refresh's babel plugin
var _c, _c2, _c3, _c4, _c5;

$RefreshReg$(_c, "SignupForm");
$RefreshReg$(_c2, "Cta");
$RefreshReg$(_c3, "Greeting");
$RefreshReg$(_c4, "HeroSection");
$RefreshReg$(_c5, "Home");

// More code for Reflame's React Refresh implementation, added using custom babel plugin
self.$RefreshReg$ = $reflamePreviousRefreshReg;
self.$RefreshSig$ = $reflamePreviousRefreshSig;
self.$reflame.registerAcceptCallback({
  pathname: '/landing/home_.tsx',
  callback: ({
    pathname,
    resourceId
  }) => {
    if (resourceId) {
      console.debug('accepting', pathname, 'to', resourceId);
    } else {
      console.debug('accepting', pathname);
    }

    self.$reflame.performReactRefresh();
  }
});

When I run SWC with a WASM plugin I just ported over doing pretty much same thing (adding code to the top and bottom of the module), here's the result:

// Code injected by swc's react refresh transform is injected first
import {jsxDEV as _jsxDEV, Fragment as _Fragment} from "react/jsx-dev-runtime";
var _s = $RefreshSig$()
  , _s1 = $RefreshSig$()
  , _s2 = $RefreshSig$()
  , _s3 = $RefreshSig$()
  , _s4 = $RefreshSig$();
// Code injected by my custom plugin is injected after
let $reflamePreviousRefreshReg = self.$RefreshReg$
  , $reflamePreviousRefreshSig = self.$RefreshSig$;
self.$RefreshReg$ = (type,id)=>{
    self.$reflame.reactRefreshRuntime.register(type, "/landing/home_.tsx" + " " + id)
}
,
self.$RefreshSig$ = self.$reflame.reactRefreshRuntime.createSignatureFunctionForTransform;

// Original module code
import*as style_ from "/style_.js";
import*as react_ from "react";

// Code injected by my custom plugin, also in the wrong order
self.$RefreshReg$ = $reflamePreviousRefreshReg,
self.$RefreshSig$ = $reflamePreviousRefreshSig,
self.$reflame.registerAcceptCallback({
    pathname: "/landing/home_.tsx",
    callback({pathname, resourceId}) {
        resourceId ? console.debug("accepting", pathname, "to", resourceId) : console.debug("accepting", pathname),
        self.$reflame.performReactRefresh()
    }
}),
// Code injected by swc's react refresh transform
$RefreshReg$(SignupForm, "SignupForm"),
$RefreshReg$(Cta, "Cta"),
$RefreshReg$(Greeting, "Greeting"),
$RefreshReg$(HeroSection, "HeroSection"),
$RefreshReg$(Home, "Home");

It looks like my plugin is running before swc's own React Refresh transform, so the swc generated code ends up wrapping my own code instead of the other way around. This breaks react-refresh entirely because the ordering between these pieces of code is significant (i.e. the code ends up calling the wrong instance of $RefreshSig$ and $RefreshReg$ otherwise).

In Babel, because the React Refresh transform is part of the react plugin, I could achieve the desired ordering just by placing them in the correct order. Since the React Refresh transform in swc is part of core, however, I don't see a way to accomplish the same thing here.

Would love to hear if y'all have ideas for how to work around this? Seems like this would be a blocker for any framework looking to use the swc plugin system to implement React Refresh, so curious if others might have already ran into it?

[kwonoj]

This has been asked in some other places couple of time, see #4826 for the context. In short, plugin need to own to run core transform and swc transform to not to perform by disable it.

[lewisl9029]

Understood, being able to disable the React Refresh transforms in core and run them as part of my plugin instead would be perfect!

Following the linked issue for updates, looking forward to testing it out when it's ready!

[meskill]

Is there any way to use builtin helpers like this in custom plugins?

helper_expr!(interop_require_wildcard, "interopRequireWildcard")

I want to implement something similar to babel's imports tranform.

[kwonoj]

Needs of transforming import in plugin is different matter indeed though.

[meskill]

I wonder why it is private as it seems might be useful in some cases like this?

Do I have any options right now to implement what I want?

[meskill]

I wonder is there was any changes in swc related to be able to insert helpers in plugins?

[kwonoj]

nothing significantly. there are some related tracking #4827 , #4826 but not about exposing helper as public.

[meskill]

thanks for the response.

we are using code below to import helper function in the transform:

            module.body.insert(
                0,
                ModuleItem::ModuleDecl(ModuleDecl::Import(ImportDecl {
                    span: DUMMY_SP,
                    type_only: false,
                    asserts: None,
                    src: Box::new("@swc/helpers".into()),
                    specifiers: vec![ImportSpecifier::Named(ImportNamedSpecifier {
                        span: DUMMY_SP,
                        local: self.helper_ref.clone(),
                        imported: Some(ModuleExportName::Ident(quote_ident!(
                            "interopRequireWildcard"
                        ))),
                        is_type_only: false,
                    })],
                })),
            );

[JiangWeixian]

@kwonoj I want to transform import path in plugin like

// before
import x from './foo'

// after
import x from './foo.cjs'

Can I access jsc.paths options in plugin? I want to detect imported path is list in project or from node_modules.

Or there is any way to apply my plugin run after swc transform @/foo -> ../foo ?

Thanks ~

[desaijay315]

@kwonoj - I want to use babel-plugin-macro within my project (not a next.js project).
I am using webpack, react 17

Currently, when I use @swc/jest, it throws the error.

MacroError: The macro you imported from "undefined" is being executed outside the context of compilation with babel-plugin-macros. This indicates that you don't have the babel plugin "babel-plugin-macros" configured correctly.

I believe babel-plugin-macro either needs an equivalent rust plugin

Any suggestion or are there any work arounds

What I have tried - configured twin.macro and read.macro, but I beleive currently it support only text file reading, but failed in configurin them :(

Let me know if any work around for using babel-plugin-macros

[kwonoj]

#4768

**Any plugin relies on babel-plugin-macro have same constraint to #4768 (reply in thread) (babel-plugin-macros pass babel object to macros) - which SWC can't provide feature parity to macro itself. We do not have any immediate plan to investigate similar approaches. **

You need to write a plugin substitutes specific macro behavior.

[coder-xiaotian]

#[plugin_transform]
pub fn process_transform(mut program: Program, data: TransformPluginProgramMetadata) -> Program {
    let filepath = match data.get_context(&TransformPluginMetadataContextKind::Filename) {
        Some(s) => s,
        None => String::from("")
    };
    
    let t = TransformVisitor { filepath: filepath };
    program.visit_mut_with(&mut as_folder(t));

    program
}

These codes will get an error "Caused by:
0: failed to invoke /Users/xiaotian/personal/tech/my-project/use-client/target/wasm32-wasi/release/swc_plugin_use_client.wasm as js transform plugin at /Users/xiaotian/personal/tech/my-project/use-client/target/wasm32-wasi/release/swc_plugin_use_client.wasm
1: RuntimeError: unreachable

• error Error: Cannot find module '/Users/xiaotian/lazy-cut/.next/fallback-build-manifest.json'"

let filepath = match data.get_context(&TransformPluginMetadataContextKind::Filename) {
    Some(s) => s,
    None => String::from("")
};

Here is my repository https://github.com/coder-xiaotian/swc-useclient.

[JSerFeng]

The file system cache seems not working, I found that when WASM is compiled, it is saved into both memory cache called compiled_module_bytes and filesystem-cache, and then all reads from the memory-cache. However when SWC process ends, the next time SWC bootstraps, it just compile WASM module again, instead of loading from the filesystem cache, because the hash cache is empty, so it cannot find the hash for the plugin name, then it cannot load from the filesystem-cache.

if let Some(fs_cache_store) = &self.fs_cache_store {
  let hash = self.fs_cache_hash_store.get(key)?;
  let store = new_store();
  let module = unsafe { fs_cache_store.load(&store, *hash) };
  if let Ok(module) = module {
      return Some(Box::new(CompiledPluginModuleBytes::new(
          ...
      )));
  }
}

Wonder if this is a bug, or I missed something here @kwonoj

[kwonoj]

It looks like oversight that store_bytes supposed to lookup the actual fs before compile a new module.

[jantimon]

we are using a swc plugin to automatically split i18n translations per chunk:

https://github.com/jantimon/i18n-next-demo/blob/main/README.md

and we are using a swc plugin for scoped css custom properties (aka css variables):

https://css-variable.js.org/

after two years it would be interesting to know if this experiment will be stable in future

[kwonoj]

If the question is wasm transform plugin will be stable, yes I believe it'll be. If the question is when, it's hard to say - there are some things would like to polish before out of experimental (or beta) potentially would bring some breaking changes. Notably things like how to configure to load plugins.

[jantimon]

would it be possible to polish it just a little bit (maybe over the next half year) and introduce an additional breaking change (with a major version bump) later?

that way I don't have to explain why our production system relies on experimental features 😄

[zhaomenghuan]

In the SWC Rust plugin, the fs API needs to be used. When the compilation target is wasm32-wasi, the fs API call does not take effect.

[Chen-jj]

How can I use HANDLER.with(|handler| {...}) in my plugin?There will be errors because of Handler haven't been set in plugin.But when I create my own handler by Handler::with_tty_emitter(ColorConfig::Auto, true, false, Some(cm.into)) and set it into HANDLER，error again cause I don‘t known where to get the cm in plugin.Please help.

[mansona]

Hey folks 👋 There was some recent movement in the linked rkyv issue related to the key question:

There is upstream issue filed for supporting it (rkyv/rkyv#164) and if we have those upstream support, it'll be relatively easy to make AST as stable interface contract.

It seems like they are suggesting that we can create a stable interface contract by managing versioned types. I know that would be a complex thing to move to but is this something that solves our problem or do we need to clarify our need in the upstream issue?

[jantimon]

This looks really interesting! A couple of quick questions:

1. I'm curious about the impact on plugin devs. If we compile these version structs, are we looking at a significant increase in plugin file size? And would this change the API for plugin authors?

2. Regarding SWC major releases: If we do a breaking release, does that mean we can clean up and remove all the structs from the previous major version?

3. Could a cli to generate these version structs be part of rkyv?

[kdy1]

A versioned struct is not viable. We need to version all AST nodes.

[mansona]

A versioned struct is not viable. We need to version all AST nodes.

yea this is why I asked the question 😭 I suspected that we would have to have versions for everything to be able to do this effectively.

Does that mean that since the upstream issue isn't likely going to be fixed (since there is a reasonable workaround for most use cases) that we will need to regroup and come up with some other solution?

[kdy1]

Yeah, sadly, that's my expectation. Or maybe think about some proc-macro-based way to workaround it.
I think it may be possible.