Community Work on an SWC Plugin

[chentsulin]

It would be nice to have a SWC plugin.
Is there a plan to integrate StyleX with Rust-based SWC as an alternative to Babel? Or, is there any team or individual currently working on this?

[necolas]

There's no plan for SWC plugin from Meta

[dgabriele]

Well, that's a bummer. I'm sure lots of people agree. I don't know the first thing it takes to integrate with SWC but anyone out there who does would be greatly appreciated if they undertook it.

[chentsulin]

Will the Next.js or SWC team plan to work on this, or will they leave it to the community to implement?
@kdy1 @leerob Sorry for mentioning, but I just want to make sure that if there's anyone want to implement the plugin, it wouldn't conflict with the plan of the teams.

[necolas]

Going to close this as "answered" and for the SWC community to support. Thanks

[denexapp]

Just wanted to mention that it's not allowed to use next/font if you use the custom babel configuration, which is required if you want to use the stylex plugin.

[nmn]

@denexapp We're aware. But we don't use SWC at Meta so we can't justify migrating to it. And maintaining two codebases is out of the question.

As StyleX grows in popularity, NextJS will eventually find a way to make it work.

[tkow]

I'm not so familiar with webpack compiler api, so my plugin had better to be improved, but I wrote plugin for next swc compiler work around modifying original next plugin. It can transpile by both swc and babel. Original plugin has problem that passes babelOption including function, causes glitch in next swc compiler. When avoiding this and set babelrc option false, swc compiler works without babel config files.
It's not swc natively support plugin using babel still but it can avoid next/font problem.

[nmn]

@tkow Will take a look at your work. We're looking to improve the integration with Next without needing a full blown SWC plugin. Since Next added support for Babel plugins alongside SWC to enable React Compiler, it should be more possible going forward.

[tkow]

@nmn
Thank you for reaction. Sorry. My previous expression may lead to misunderstand. It's babel plugin with trivial modification from @stylex/next-lugin though It looks that rewrite https://github.com/facebook/stylex/tree/main/packages/nextjs-plugin widely and unreadable because I wrote as soon as possible to make it work around soon.
However, in fact, except for rewriting typescript for comfortable for me for experiment of rewriting it, there are only three important points to adapt nextjs compiler using babel.

1. Next.js Compiler doesn't seem to accept unserialized value like function as babelOptions in loader when it uses webpack's hook , so I move transform function into webpack loader from webpack plugin initialization
2. For 1 statements, webpack compiler objects value can't be passed to loader except for itself calls hook, so we need to emit change from webpack loader scopes' compiler though it's not clear why but it can update passed object value.
3. For development, we want to reflect changes of stylex files, but they don't be detected and update css files until server's restarted with original code. I don't know why, but css files are not found in PROCESS_ASSETS_STAGE_PRE_PROCESS hook when emitting a change event from loader, so I must keep css file names cached at first event and write files directly by them when it calls more than two times. It reflects when it's reloaded and doesn't support hmr, so I don't have confidence that it's optimal and suite for the case, It can be improved.

My team's really moved by stylex's awesome design system and wanted to use it our product soon, so published it our own way but I would like you to improve your original plugin about the points I described if possible.

[nmn]

@tkow We are looking at biggest improvements for next.js right now. Will have a better solution soon.

[Dwlad90]

Hi, @necolas, @nmn!

I have been working on SWC plugin for StyleX as an alternative for the official Babel-based library and now feel like it’s ready for public usage. The main goal of the plugin is to drop Babel and use SWC instead.

This plugin is ready for usage, as it passes almost 100% of original babel plugin tests.

This might be especially useful for Next.js projects as it allows to use Vercel’s SWC-based Next.js Compiler (which is disabled if a Babel config is present in the project).

I have a question about naming the package. I am not sure if the current name can confuse people into thinking this is an official plugin (and how ok are you with it)? In documentation, I have tried to make it as clear as possible that this is an unofficial plugin, but would love your feedback on this.

I haven’t followed the discussions as much lately and not sure if there is a place / platform which gathers unofficial StyleX-related plugins and extensions. If there is such a place, I would love to reach out to the maintainers and ask them to add this plugin there.

And, of course, thank you for your work! StyleX is a great library.

P.S.
Repo: https://github.com/dwlad90/stylex-swc-plugin
Sandbox with example Next.JS application: https://codesandbox.io/p/github/Dwlad90/nextjs-app-dir-stylex/main

[nmn]

@Dwlad90 This plugin was brought to my attention already! I have been very busy for a while, but I plan to dig into your implementation soon. For now it makes the most sense for us to support the independent development of the SWC plugin. Eventually, I would love to share more code or even make it a part of the official implementation.

The name is OK with us as all official StyleX packages are under the @stylexjs namespace.

Thank you!!

[Dwlad90]

@Dwlad90 This plugin was brought to my attention already! I have been very busy for a while, but I plan to dig into your implementation soon. For now it makes the most sense for us to support the independent development of the SWC plugin. Eventually, I would love to share more code or even make it a part of the official implementation.

The name is OK with us as all official StyleX packages are under the @stylexjs namespace.

Thank you!!

Thank you,
Will be glad to continue the development. Would be glad to collaborate in the future if you ever decide to make an official implementation.

For now, Is this possible to add this plugin to the Ecosystem page on the documentation website? If so I can open a PR with this.

[SukkaW]

@Dwlad90

The SWC plugin does have limitations: it lacks first-party metadata output (requiring comment and regex extraction) and it's bound to SWC (necessitating the use of swc-loader or rollup-plugin-swc3).

I propose an alternative approach. Instead of building an SWC plugin, we could leverage SWC's existing infrastructure (parser, transformer, etc.) to create a dedicated Rust-based Stylex transformer using napi-rs. It would work as follows:

import { transform } from 'stylex-compiler-rs';

const { stylexRules, code, map } = transform(input, options);

This method offers better integration with webpack/vite/rollup and doesn't suffer from the metadata limitations.

I've discussed this with one of the SWC team members, @Austaras, who has expressed interest in assisting when he has available time. What are your thoughts on this?

[Dwlad90]

@Dwlad90

The SWC plugin does have limitations: it lacks first-party metadata output (requiring comment and regex extraction) and it's bound to SWC (necessitating the use of swc-loader or rollup-plugin-swc3).

I propose an alternative approach. Instead of building an SWC plugin, we could leverage SWC's existing infrastructure (parser, transformer, etc.) to create a dedicated Rust-based Stylex transformer using napi-rs. It would work as follows:

import { transform } from 'stylex-compiler-rs';



const { stylexRules, code, map } = transform(input, options);

This method offers better integration with webpack/vite/rollup and doesn't suffer from the metadata limitations.

I've discussed this with one of the SWC team members, @Austaras, who has expressed interest in assisting when he has available time. What are your thoughts on this?

Hi @SukkaW,

thanks for the great recommendation, i hadn't heard of napi-rs before.

This is an interesting approach and I would be interested to get to learn this technology and participate in the implementation of the StyleX napi transformer

[kdy1]

swc creator here. I can also help if you want to go in that direction.

[Dwlad90]

@Dwlad90

The SWC plugin does have limitations: it lacks first-party metadata output (requiring comment and regex extraction) and it's bound to SWC (necessitating the use of swc-loader or rollup-plugin-swc3).

I propose an alternative approach. Instead of building an SWC plugin, we could leverage SWC's existing infrastructure (parser, transformer, etc.) to create a dedicated Rust-based Stylex transformer using napi-rs. It would work as follows:

import { transform } from 'stylex-compiler-rs';

const { stylexRules, code, map } = transform(input, options);

This method offers better integration with webpack/vite/rollup and doesn't suffer from the metadata limitations.

I've discussed this with one of the SWC team members, @Austaras, who has expressed interest in assisting when he has available time. What are your thoughts on this?

@SukkaW, @kdy1,

Link to RFC with napi-rs compiler

[nmn]

This is all very exciting! I'll be trying to contribute more in the coming months to this effort.

Also, reopening this issue and updating the description for ongoing conversations about this work.

[necolas]

Moving this to a discussion