react-strict-dom

ships its calls uncompiled by design — the consumer compiles them, and extracts the resulting rules into via . In that arrangement an app's own StyleX styles sit in later layers and correctly override the element defaults. A consumer that pre-compiles the package instead gets a different result. Compiling with on emits calls, and the runtime path applies specificity boosts into an unlayered stylesheet. (Our reason for pre-compiling is import safety in a test runner that externalises the package, so it reaches the runtime uncompiled: each carries a at module scope, and throws on it by design. #265 is the same error in a Vite context and #273 the general pre-compiled-library case — both closed as completed, and neither concerns the cascade consequence below, which is what this issue is about.) Unlayered rules outrank every layered rule, regardless of specificity or source order. So the same element defaults flip from "overridable by the consumer" to "overriding the consumer". Observed Identical class names in both arrangements — the divergence is purely cascade position, so every name-level comparison passes: beat the app's own padding on every element carrying both classes. Rendered result: nav items running together, button text overflowing its pill, header clipped. The build, the tests and a name-level fidelity check were all green throughout. The gap The two supported paths for the same package produce different cascade semantics, and nothing surfaces that. A consumer who pre-compiles for import safety silently gets reset rules that outrank their own styles. The smallest fix is documentation: pre-compiling requires plus consuming the emitted rules through . That is what we now do — the rules ship as a CSS sidecar the app imports, so layer assembly is delegated to the same function the postcss plugin uses rather than reimplemented against a mapping that could drift. A stronger fix would be to ship a pre-compiled entry point, so import safety never requires a consumer to choose an injection mode at all. Related The companion issue https://github.com/facebook/stylex/issues/1806 covers the naming half of the same contract. Together: a library's style output should be invariant to how the library was compiled — in the names it derives and in the cascade address those names are delivered to.**

Summary The validation in the constructor throws the wrong error message. It reports a damping problem when an invalid mass is supplied, because the message was copy-pasted from the preceding damping check. A user passing (or a negative mass) gets told their damping value is wrong, which points them at the wrong config field. React Native's equivalent throws here. Fix Use the correct message for the mass check. Test Added covering all three constructor validations (stiffness, damping, mass). The mass case fails on (asserts ) and passes with the fix. and are clean. Reopening this. I closed it by accident during a bulk cleanup of my stale forks and cannot reopen the original because the fork was deleted, so this is the same branch restored. Sorry for the noise @MoOx.

Fixes #452 On native, returning for a property from an inline style function (or any style object with an undefined value) leaks that key through and into the style resolver, which throws . This is a regression; these values used to be dropped, and on web undefined values are simply ignored. The loop in branches on //, so an undefined value falls through to the catch-all assignment and ends up in the result as . This adds an early for undefined values so the property is omitted, matching web behavior and letting inline style functions return undefined to opt out of a property. is left untouched since the resolver accepts it. Testing: added a regression test under that asserts the property is absent when the inline function returns undefined. Confirmed it fails on and passes with the fix. Full native + web jest suites pass (888 tests, 711 snapshots unchanged), Flow and ESLint clean. Reopening this. I closed it by accident during a bulk cleanup of my stale forks and cannot reopen the original because the fork was deleted, so this is the same branch restored. Sorry for the noise @MoOx.