Last 12 weeks ยท 69 commits
5 of 6 standards met
Description When using with computed property keys in , the Vite dev server crashes with an "Invalid empty selector" error from lightningcss. This is a timing issue specific to dev mode โ it does not affect production builds. Root Cause StyleX's mechanism works via a two-phase system: 1. When the babel plugin processes files, it generates "constant rules" with / metadata 2. When it processes consumer files (using computed keys like ), it generates rules with as CSS selectors 3. At CSS generation time, replaces references with actual values from the constant rules In production builds, all files are transformed before runs, so constant rules are always available and the replacement works correctly. In the Vite dev server, CSS can be requested/regenerated before all files have been processed. When this happens: doesn't find the constant values in references remain unresolved in the CSS output (e.g. ) in rejects this as invalid CSS, throwing "Invalid empty selector" The dev CSS middleware crashes The HMR mechanism () would eventually re-trigger CSS generation once all files are processed, but the error prevents the dev server from serving any CSS in the meantime. Reproduction 1. Create a file: 2. Use computed keys in a consumer file: 3. Run the Vite dev server โ the terminal shows: Proposed Fix Wrap the call in () in a try-catch, falling back to the raw CSS output: This is safe because: The raw CSS with selectors is ignored by the browser (invalid selectors are skipped) Once all files are processed, the next HMR-triggered CSS update resolves all references and produces valid CSS Production builds are unaffected (all files are always processed before CSS generation) Environment : 0.17.5 : 0.17.5 Vite: 8.0.0-beta.8 Node: 22
What changed / motivation ? WebkitAppearance was restricted to only 'textfield' while the standard appearance property accepts 'auto', 'none', and 'textfield'. Reuse the existing appearance rule so the vendor-prefixed variant allows the same values. Seen like a copy-paste? Linked PR/Issues n/a Additional Context n/a Pre-flight checklist [x] I have read the contributing guidelines Contribution Guidelines [x] Performed a self-review of my code
Repository: facebook/stylex. Description: StyleX is the styling system for ambitious user interfaces. Stars: 9129, Forks: 392. Primary language: JavaScript. Languages: JavaScript (93.2%), MDX (3.5%), TypeScript (3.2%), CSS (0.1%), Shell (0%). License: MIT. Homepage: https://stylexjs.com Latest release: 0.17.5 (1mo ago). Open PRs: 25, open issues: 95. Last activity: 2d ago. Community health: 87%. Top contributors: nmn, mellyeliu, necolas, henryqdineen, nedjulius, Prakshal-Jain, nonzzz, dwei-figma, Jta26, vincentriemer and others.
JavaScript
Implementation Adding support for inline styles authoring with a new package. This allows you to write styles inline in that are pre-compiled within the props visitor using much of the logic for static and dynamic styles. This is something we went back and forth on a few times, but ultimately felt that it's good to provide the optionality. We still recommend (and want to bake in enough friction) for people to use namespaces for the majority of usecases for readability/maintainability reasons. The naming of all the above is up for discussion, as well as what styles we should build into this API. I'm also using type from estree for type checking for a first pass, but there might be something better we can use. Testing Style types: [x] Static values [x] Leading underscores [x] Object key syntax [x] Dynamic inline styles Tested within docs page the above + [x] Different merges of dynamic, regular, and inline styles [x] Named imports Deferring to follow ups: [ ] Rethink contextual styles [ ] Make work with valid-styles / some way to add linter validation [ ] Add docs [ ] Rethink package name + standard import alias [ ] figure out import and package naming?
RFC: for ergonomic custom property names in Summary This RFC introduces a new compile-time helper: It lets developers keep ergonomic dot-notation keys in while explicitly choosing the emitted CSS custom property name. Example: This preserves usage ergonomics () and emits explicit custom property names (, ). Motivation Current patterns force a tradeoff: 1. Hash-based var names are ergonomic but not explicit. 2. Legacy explicit custom names via keys are explicit but less ergonomic for dot-notation authoring. We want both explicit naming and ergonomic authoring, with hard-fail diagnostics when misconfigured. Goals 1. Keep dot-notation variable references ergonomic. 2. Allow explicit custom property names in . 3. Fail loudly and actionably on invalid declarations. 4. Preserve cross-file correctness for imported theme references. 5. Keep legacy behavior fully supported. Non-goals 1. No runtime execution semantics for . 2. No auto-prefixing missing . 3. No relaxation of static-analysis constraints. API Design New API must be: 1. A static string literal at compile time. 2. Prefixed with (mandatory). 3. A valid CSS custom property name under strict validation. supports existing value shapes, including conditional objects and typed values. Validation contract (hard-fail) Compilation fails with actionable errors when: 1. is missing the prefix. 2. is dynamic/non-static. 3. violates syntax validation (). 4. Multiple declarations resolve to the same custom property name. 5. collides with legacy declarations. Runtime behavior is compile-time-only. If uncompiled code reaches runtime, it throws a clear error instructing users to ensure StyleX compilation is correctly configured. Detailed Behavior Transform semantics 1. If a value uses , is used as the emitted property name instead of hash generation. 2. The wrapped is unwrapped and processed through existing logic, including conditional and typed variable handling. 3. Mixed declarations are supported: regular hashed variables and explicitly named variables can coexist in the same object. Cross-file theme reference semantics Imported references preserve explicit names from both: 1. , and 2. legacy keys. If imported declarations are invalid, compilation fails deterministically with cause-preserving diagnostics. Diagnostics This RFC adds specific error modes for + : 1. Missing required prefix. 2. Invalid custom property syntax. 3. Dynamic/non-static name argument. 4. Duplicate custom property name collisions. 5. Invalid call shape (argument count, etc.). All failures are hard errors with code-frame context and remediation guidance. Backward Compatibility 1. Existing usage remains valid. 2. Existing legacy explicit custom property keys () remain valid. 3. This change is additive for valid programs and stricter for invalid ones. Alternatives Considered 1) Auto-prefix missing Rejected. Auto-prefixing hides mistakes and reduces predictability. Mandatory prefixing creates explicit intent and better diagnostics. 2) Object wrapper syntax Example: . Rejected due to weaker ergonomics, easier accidental misuse, and less clear compile-time intent than a dedicated helper call. 3) Keep only legacy keys Rejected because it does not preserve ergonomic dot-notation authoring patterns. Test Plan 1. Transform tests validate explicit-name emission, conditional values, typed values, and mixed named/hashed usage. 2. Validation tests cover missing prefix, invalid syntax, dynamic names, and duplicate/collision errors. 3. Evaluate-path tests verify imported refs resolve explicit names and invalid imported declarations fail deterministically. 4. Runtime API tests verify the uncompiled runtime stub throws with actionable guidance.