feat: add CSS @property rule support

[YevheniiKotyrlo]

Problem

Tailwind CSS v4 uses ~53 @property declarations to register custom property initial values (e.g., --tw-shadow, --tw-ring-shadow). Previously, react-native-css ignored @property rules entirely and faked -moz-orient support to trigger Tailwind's @supports fallback path. This fallback injected universal variable defaults which interfered with class-level overrides, causing utilities like ring-2 to produce boxShadow: [].

The @property approach is generic and framework-agnostic — this is the direction suggested during the #277 review.

Changes

src/compiler/compiler.ts

Parse @property rules, extract initial-value into root variables via extractPropertyRule / parsePropertyInitialValue. Handles length, number, percentage, color, angle, token-list, custom-ident, and repeated component types.

src/compiler/stylesheet.ts

Add addRootVariable() public method following the existing variable storage pattern.

src/compiler/supports.ts

Remove the -moz-orient hack (no longer needed).

src/native/styles/shorthands/_handler.ts

Allow StyleFunction values (calc, var) to pass type checks in the shorthand handler. These are unresolved at pattern-match time but resolve to the correct type at runtime — rejecting them would break variable-based shadows entirely.

src/native/styles/shorthands/box-shadow.ts

Fix color type from "string" to "color" to accept platform color objects (e.g., PlatformColor from currentcolor resolution).

Tests

• 12 compiler tests for @property parsing (including single-child and multi-child repeated types)
• 2 runtime tests for box-shadow @Property defaults and currentcolor matching

Verification

• yarn typecheck — pass
• yarn lint — pass
• yarn build — pass (no unstaged files)
• yarn test — 990 passed, 3 failed (pre-existing babel plugin failures, same on main)

Related

• Companion to feat: add inset shadow parsing support #277 (now merged) — implements the @property approach suggested during that review
• fix(types): move @types/debug from devDependencies to dependencies #290 (merged) — @types/debug dependency fix in the same repo

[danstepanov]

@YevheniiKotyrlo mind rebasing this with main?

[YevheniiKotyrlo]

Done — rebased on latest main. Stack is clean: commit 1 is #277 (inset parsing), commit 2 is this PR (@Property support). All quality gates pass.

[danstepanov]

Nice work on this, the @Property approach is way cleaner than the -moz-orient hack. Two things:

1. Comment on the isStyleFunction passthrough (_handler.ts)

Accepting any style function in any type slot is the right call — but it's non-obvious. A future reader might wonder why var(--x) matches a "number" slot. Can you expand the comment a bit to explain the tradeoff? Something like: "this makes pattern matching less strict when variables are involved, but rejecting them would break variable-based shadows entirely."

2. repeated single-child unwrap (compiler.ts)

return results.length === 1 ? results[0] : results;

This changes the return shape depending on child count. Could you either add a test with a single-child repeated to confirm it works downstream, or add a comment noting that no real-world @property declaration hits that path?

[danstepanov]

Can you also resolve the conflicts since I merged #277, ideally via a rebase

[YevheniiKotyrlo]

Rebased on latest main (b0b35b1, includes merged #277). Conflicts resolved — single clean commit.

Addressed both review comments:

1. isStyleFunction comment expanded — now explains the tradeoff: accepting unresolved functions makes pattern matching less strict when variables are involved, but rejecting them would break variable-based shadows entirely (e.g. box-shadow: var(--shadow) where --shadow resolves to 0 4px 6px -1px #000).

2. repeated single-child unwrap — added two tests proving the behavior:

   • @property with repeated single-child unwraps to scalar — <length>+ with 10px produces [[10]] (same shape as direct <length>)
   • @property with repeated multi-child preserves array — <length>+ with 10px 20px produces [[[10, 20]]]

   Also expanded the inline comment to clarify why the unwrap exists.

All quality gates pass (typecheck, lint, build with no unstaged files, test — 990 passed, 3 pre-existing babel failures same on main).

[danstepanov]

LGTM