Why doesn't the Jest transformer process vanilla files?

[sebtoombs]

Hey all 👋

I've been using vanilla-extract to build an isomorphic styling library. The library exposes a theming API which has 2 adapters, 1 to vanilla-extract for static styles, and 1 to emotion for runtime styles.

I've been leveraging the function serializer (from @vanilla-extract/css/functionSerializer) to switch between adapters, and it works nicely! I've recently run into an issue where a project using my library and testing via Jest hits the "styles were unable to be assigned to file" issue when part of the application tries to generate (what it expects to be) runtime styles. Because the Jest transformer hasn't run processVanillaFile, as far as the library knows we're still in "static mode", and vanilla-extract has a fit because the calling file isn't a .css.ts file (fair enough).

I notice that the Vite (Vitest) transformer does call processVanillaFile.

Solving this problem is of course complicated because processVanillaFile is async and Jest (except for in ESM mode) needs to process synchronously.

Anyway, wondering if there's a reason for this, or maybe it's just an oversight? It's probably an incredibly niche, isolated problem 😅 - although I do wonder if it's related at all to some of the other issues I can see regarding Jest issues with Next?

FWIW I have implemented a rough synchronous transformer that does process vanilla files which solves my problem (but its a fair bit of copy-pasted code from VE...)

Thanks folks!

[sebtoombs]

Little update on this one; I discovered my solution (processing the file) solved my function serialization issue, but introduced another issue (which may be the original reason the team didn't do this).

When the files are processed, the css is extracted during the eval step, (I'm assuming this is a Jest order-of-operations problem), and doesn't hit the test DOM. I tried adding a custom runtime adapter but no avail - it appears the JSDOM document isn't available at transform time.

I've worked around this (kinda) for now by evaluating vanilla files and only processing those that contain serialized functions. This has the obvious issue that if a file contains both css and serialized functions the css will be lost. If anyone has a better understanding of how Jest/JSDOM work here I'd be happy to investigate further.

Edit: I've "fixed" my issues by adding a css adapter and then injecting the css in the returned code from the transform.

I'd love to see if there is any feedback from the maintenance team - I'd be happy to open a PR for a solution if there is appetite for it.

[sebtoombs]

Hey @Golodhros , you just use it like any other jest transformer. See the jest docs: https://jestjs.io/docs/code-transformation

I'm not sure what you mean by Jest + vitest - these are separate test runners? And we don't have the luxury of switching test runners right now in these projects. using Vitest instead of Jest could by all means solve the issue.

Also in my case we are not using Nextjs - this issue just appears to be the same issue Nextjs users are seeing.

[janbiasi]

Hey @sebtoombs & @Golodhros

The main difference when using Next.js is, that Next.js always overrides the CSS processing configuration of Jest so there's literally no option of overriding it - see #1131 (comment). I'd recommend to take a look at https://stylexjs.com/ instead :)

[Golodhros]

Thanks @sebtoombs!
Oh, yeah, my mistake, I wanted to say vitest + VE + next.js.

@janbiasi you mean that even if I plug @sebtoombs workaround transformer, it wouldn't be applied by NextJS anyways, right?

We are in this situation where the team was in the middle of migrating from Stitches to Vanilla Extract, but didn't wrote many unit tests. Now we might need to start migrating all over again :(

[janbiasi]

@Golodhros yes, exactly. There's no way to override the Next.js internally applied transformer.
I'm very sorry, but maybe you can find another intermediate solution like using vitest for tests instead.

[Golodhros]

Thanks @janbiasi !
I have a proof of concept with vitest and it seems it works fine. We'll go that route!