☂️ Roadmap for a Rust-based compiler

[layershifter]

💡 This issue will be updated as we go.

TL;DR

We want to have nice, modern and blazing fast compiler ⚡ We aim to support Linaria & Griffel.

Dev design

TBD

Initial context could be found there, microsoft/griffel#621.

API design

We will continue to expose processors as the interface. Processors will implement actual transforms and should be written in Rust. We will continue provide plugins/loaders for bundlers.

We expect that the usage will look like that:

// vite.config.ts
import wyw from '@wyw-in-js/plugins/vite'
import linaria from '@linaria/wyw'

export default {
  plugins: [wyw(linaria, { /* some options */ })],
}

Roadmap

TBD

[nstepien]

Does that mean Linaria will finally stop trying to evaluate modules? 😮

[paulm17]

When targeting Vite. Will voidzero be used? I hear a lot of talk about simplifying things re: transforms, etc.

[brijeshb42]

Is this open for contribution ?

[layershifter]

Does that mean Linaria will finally stop trying to evaluate modules? 😮

@nstepien nope, we will continue to evaluate modules, but the goal is to make it faster and simpler.

When targeting Vite. Will voidzero be used? I hear a lot of talk about simplifying things re: transforms, etc.

@paulm17 not sure that I got it.

We will use OXC toolkit (parser, resolver, transformer) as our core dependency as OXC is funded by voidzero.

Is this open for contribution ?

@brijeshb42 yes.

You will see some Rust code making its path to the main branch soon. The current problem that we don't have something working end to end 🙃

I plan to solve this soon and also add more clarify on the plan, but I don't want to make broken promises for now.

[paulm17]

@paulm17 not sure that I got it.

If you hear Evan talk about how voidzero operates compared to the current paradigm. You'll understand. 😄 But regardless, you answered my question.

The last time I looked at OXC was in the summer and found the transform wasn't feature complete. So much so that Next-Yak went with SWC.

I've been watching this space with interest. So excited to see how this will all unfold.

[nstepien]

nope, we will continue to evaluate modules, but the goal is to make it faster and simpler.

That's a shame, module evaluation is the biggest pain point with using Linaria: it leads to build failures and slow builds.

[GriffinSauce]

Hi @layershifter - this seems to be mostly internal to wyw-in-js, does it affect support for SWC and other bundlers like Turbopack at all?

I'm still parsing how this project, Linaria and the build tools all fit together, so apologies if the answer should be obvious. We have a set of Next.js apps which we've migrated to Linaria to improve performance for users but now we're locked into Babel and Webpack. (SWC and Turbopack have huge impact for us, some of the apps are quite big).

So I'm curious whether this is related, I did see #53

Thanks!

[layershifter]

@GriffinSauce

FYI SWC is not a bundler yet (https://swc.rs/docs/usage/bundling) 🐱

does it affect support for SWC and other bundlers like Turbopack at all?

No, this does not affect Turbopack support. Considering that it's not production ready (https://areweturboyet.com/) & lack of public documentation, there are no currently plans to look into that direction from my side.

[GriffinSauce]

@GriffinSauce

FYI SWC is not a bundler yet (swc.rs/docs/usage/bundling) 🐱

does it affect support for SWC and other bundlers like Turbopack at all?

No, this does not affect Turbopack support. Considering that it's not production ready (areweturboyet.com) & lack of public documentation, there are no currently plans to look into that direction from my side.

Thanks, that was poor wording on my part. I'm looking for a path forward to use SWC as the transpiler (with webpack). This is the default Next configuration now. Thanks for the clarity on Turbopack, that makes a lot of sense at this point.