stylex icon indicating copy to clipboard operation
stylex copied to clipboard

inconsistent priority/ordering when using stylex based 3rd party library

Open pycraft114 opened this issue 3 months ago • 3 comments

Describe the issue

We’ve built our design system with StyleX and published it as an npm package. We also have a separate Next.js project that consumes this library. That project uses our third-party library and also applies its own styles directly with StyleX.

While inspecting elements, we noticed something odd: the “computed styles” list shows rules coming from a plain

Is this expected behavior?

Image Image

Expected behavior

Only the styles from our third-party package (the library we built) should be applied.

Steps to reproduce

Since we are using our own private package we couldnt provide a reproduction. tho further questions are welcomed

Test case

No response

Additional comments

No response

pycraft114 avatar Aug 25 '25 08:08 pycraft114

we figured out that we are using debug and dev mode as true since we are testing locally which lead to inject style in runtime.

But we do have persisting problem that we want to solve

In a Next.js consumer app that uses StyleX locally and also imports our design-system package (built with StyleX), atomic rules defined in both places end up with the same class name (e.g., white-space: nowrap → .xuxw1ft). However, the locally generated CSS consistently overrides the library’s CSS.

What we see

In Sources:

layout.css — contains our design-system package styles (imported in layout).

stylex-webpack-generated.css — contains locally defined StyleX rules (generated by the SWC/webpack StyleX plugin).

For the same atomic (e.g., white-space: nowrap), both files contain .xuxw1ft.

The rule from stylex-webpack-generated.css wins because:

layout.css entries include priority metadata.

stylex-webpack-generated.css (local) entries appear to be emitted without a priority.

As a result, local atoms always take precedence over greet atoms when they collide.

We’d like only the styles from our third-party library to apply when the same atomic is already provided there, or at least have consistent priority/ordering so the library styles are not unconditionally overridden by app-local ones.

_stylex-webpack-generated.css file is kept injected on top level of html

pycraft114 avatar Aug 26 '25 01:08 pycraft114

_stylex-webpack-generated.css

@pycraft114

Based on that filename, it seems that you are using my webpack plugin stylex-webpack. Would you like to try the latest major version (0.4.2)? I have made a few adjustments to CSS generation https://github.com/SukkaW/stylex-webpack/pull/6

Also, is that design-system package pre-compiled? Ideally, packages like design-system should not be pre-compiled and should publish the source code directly (retaining import '@stylexjs/stylex' and stylex.create()).

You should then include design-system in Next.js config's transpilePackages, which tells Next.js to use its stylex plugin (in your case is my stylex-webpack) to compile both StyleX from your Next.js app and design-system.

In short, always use one compiler to compile both parts of the StyleX rules in one pass.

SukkaW avatar Sep 04 '25 21:09 SukkaW

  1. You should never use runtimeInjection in a next app with app dir.
  2. Are you sure you're not pre-compiling the design system package?

nmn avatar Sep 07 '25 03:09 nmn