How about stylex/lingui?

[nikita-starostin]

Hey, thank you for the great work on Remix Next. The thing I like the most since the previous Remix is the elegance of the code and its good architecture - writing the loader and component in one file was massively cleaner than anything I have ever tried for writing async code for a component.

I like a lot of things in the new Remix, including let for state, clientEntry, and <Frame>, routes, but I can't easily bring in a few libraries that I like - StyleX and Lingui - since they have a compilation phase.

Lingui basically allows you to write <span>{t'Hello, I am translated'}</span>, providing super readable and easy code with locale checks during compile time.

StyleX is a combination of atomic styles, TypeScript support for variables, zero runtime cost, and predictable style merging. It also achieves its goals through compilation by producing native CSS at the end.

I was considering migrating for Remix 3, but those libraries are an important part of the codebase, so for now I’m going to stay on React Router Framework.

[sergiodxa]

What prevents you to use them? If it's because there's no build step anymore, that's is because the Remix doesn't need one, not because it's forbidden.

You can install Vite or any other compiled and it should work, I do it for my apps on Cloudflare Workers.

[nikita-starostin]

Thank you, got it. I’ve actually found a few options:

1. For the Node environment: use registerHooks + a custom loader for the assets server to apply transformations to files on demand.
2. Add Vite to actually build the app while preserving modules and redefine assets to serve from the build.
3. Replace the assets server with a Vite adapter.

For now, I’m staying with option 1 and investigating option 3 for the future.

I think that once I’m familiar with option 3 (already understand how to do it, but haven't checked yet), I’ll be ready to use Remix 3

PS. helpful example, thanks, https://github.com/sergiodxa/remix-v3-demo

[Kin230k]

I would evaluate those three options as a transform contract, not only by whether they start the development server. For Lingui and StyleX, the important invariant is that the server and browser consume the same transformed module graph on every deployment target.

A useful probe app could keep a loader and component in one route module, render one extracted Lingui message during SSR, hydrate it, switch locale on the client, and include one StyleX rule in both an eagerly loaded and a lazy route. Run that fixture in development and production for Node and a Workers-style runtime, then assert: no untranslated message IDs, no hydration mismatch, stable CSS order and class hashes, one transform per module, working source maps, and invalidation after editing a message or style. That would also expose whether a runtime hook only transforms the server graph while the browser graph follows a different path.

The cleanest option is the one that can document a single owner for transformation, cache keys and invalidation, and the boundary between source modules, emitted assets, and the assets server. Option 1 may remain useful for Node-only experiments; option 2 needs to prove that the preserved-module output is what both the server and asset pipeline actually import; option 3 can make the adapter that explicit integration point. This gives third-party compilers a portable acceptance contract without requiring Remix itself to become their compiler.