What is the future of the old experimental js plugin?

[nbouvrette]

Thanks for starting this discussion @kwonoj

I was about to write a new SWC plugin today and saw no mentions of JavaScript/TypeScript in the documentation which caught me off guard.

I was reading your initial intro and I am a bit worried about:

I expect eventually javascript plugin will be considered as legacy.

Would you say it would be counterproductive for me to write a new JavaScript plugin?

Unless I a missing something, if you want a plugin that works both the same way with Babel and SWC, it will be pretty tricky because they are using different languages. For example, I was hoping to port this Babel plugin to SWC and it uses other npm packages which won't be available in Rust.

On top of that, for my specific use case, I want to pass custom parser functions to the plugin (as an argument) - I also don't see how this will be possible with a Rust plugin.

How are you planning to support these use cases in the future?

[kwonoj]

I'm probably not able to give any concrete final decision, can only share what we know today. In here, I'll call JS based plugin as legacy for the clear distinction between new experimental plugin.

1. Legacy will not go away in a day or two. We have a lot of internal discussions about the right paths for the plugin ecosystem and nothing's concluded fully for the legacy yet.

2. However, the new plugin system will be first class citizen to get most of the support at this moment.

3. You may decide to write legacy plugin still, but you have to keep in mind that was only available for the node.js bindings from beginning. @swc/wasm was not able to run legacy plugins. New native cli (rust-based) will be the same. SWC have lot of target platforms other than direct node.js bindings which we can't / didn't / won't support running JS (or more broadly, node.js packages). Also some of ecosystem (like next.js) never supported legacy plugin from beginning so you may not able to support all of the users.

4. Even if you choose to use legacy plugin, it doesn't change you can't make it work in both between SWC and Babel: Please note SWC does not share the same AST architecture / visitors / and other surroundings. Of course, you won't need to deal with another language and possibly utilizing some of node.js ecosystem 3rd party package if you're using JS though.

5. The general design approach of the new plugin system is preventing users from injecting user level code, specifically JS functions. Yes, as you pointed out it's somewhat common pattern for some usecases we may need to invent different approaches to support for it. But this is directly connected to the root reason we choose to not pursue JS based plugins - the performance bottleneck for the serialization / deserialization itself, as well as uncontrollable performance prices come from famous plugin's user-level code degrades general performance of SWC over time which we'll be impossible to solve in the future. We do understand this problem domain and trying to evaluate a couple of possible approaches, even though we do not actively work on this. (Stabilization & widening platform support are current priorities)

[nbouvrette]

Thanks a lot for such a detailed answer.

I am a bit disappointed that Next.js does not support the SWC legacy plugin because that is the main use case I had in mind.

And you are right, I was planning to re-write an SWC version of the Babel plugin but I would expect to have the same behavior when used with a different compiler (and ideally re-use a lot of code).

My use case is a bit atypical because it's more of a "plugin generator" that would work across compilers - I had a cool picture in my mind but given the info you shared I will probably put this on ice for now.

Feel free to loop me into these discussions if you ever need external input on this topic!