@blotch/rsbuild-plugin-angular-lynx 22.2.3 → 22.2.4

package/dist/tailwind-v4/calc.d.ts

@@ -0,0 +1,18 @@
+/**
+ * Folds every `calc()` in a value whose terms are all constants, such as the
+ * `calc(45deg * -1)` and `calc(calc(1 / 2 * 100%) * -1)` Tailwind writes for
+ * negative and fractional transforms, into a single value (`-45deg`, `-50%`).
+ *
+ * Lynx evaluates `calc()` in lengths, but not everywhere a transform function
+ * takes an angle, a number or a percentage, so the transform values are
+ * folded before they reach it. A `calc()` with `var()` or mixed units stays
+ * as it is. So does `infinity`, which Lynx doesn't read.
+ */
+export declare const foldCalc: (value: string) => string;
+/**
+ * Replaces a number written with an exponent of 7 or more, with the stand-in
+ * for `infinity`. In a production build Tailwind minifies with Lightning CSS,
+ * which folds `rounded-full`'s `calc(infinity * 1px)` to the largest float,
+ * `3.40282e38px`, and Lynx doesn't read an exponent.
+ */
+export declare const clampHugeNumbers: (value: string) => string;

package/dist/tailwind-v4/calc.test.d.ts

@@ -0,0 +1 @@
+export {};

package/dist/tailwind-v4/colors.d.ts

@@ -0,0 +1,6 @@
+/**
+ * Rewrites every color function in a declaration value that it can evaluate
+ * statically. A function with `var()`, `calc()` or another dynamic part stays
+ * as it is: Lynx drops it, as before.
+ */
+export declare const lowerColors: (value: string, channelVariables?: ReadonlySet<string>) => string;

package/dist/tailwind-v4/colors.test.d.ts

@@ -0,0 +1 @@
+export {};

package/dist/tailwind-v4/declarations.d.ts

@@ -0,0 +1,39 @@
+import type { Root, Rule } from 'postcss';
+/**
+ * Rewrites the declarations Tailwind CSS 4 writes into ones Lynx reads. Each
+ * rewrite keeps what the declaration means on the web, so the web preview
+ * and the native app keep matching.
+ */
+/**
+ * The single `transform` the `translate-*`, `rotate-*`, `scale-*`, `skew-*`
+ * and `rotate-{x,y,z}-*` utilities all write, composed from the variables
+ * each of them sets.
+ *
+ * Tailwind 4 writes the `translate`, `rotate` and `scale` properties, which
+ * Lynx doesn't have, so the utilities would do nothing on device. Lynx's own
+ * Tailwind 3 preset composes the same way. The order is the one CSS applies
+ * the individual properties in: translate, rotate, scale, then `transform`.
+ */
+export declare const COMPOSED_TRANSFORM: string;
+/**
+ * The starting values of the variables {@link COMPOSED_TRANSFORM} reads that
+ * must be set for it to parse. The others have empty fallbacks.
+ */
+export declare const TRANSFORM_DEFAULTS: ReadonlyMap<string, string>;
+/** What lowering a rule's declarations found, for the defaults rule. */
+export type LoweredRule = {
+    /** Whether the rule now writes {@link COMPOSED_TRANSFORM}. */
+    readonly composesTransform: boolean;
+};
+/**
+ * Lowers every declaration of one rule. Works on the rule as a whole because
+ * the transform properties collapse into one declaration. `channelVariables`
+ * are the colors the stylesheet gives a `-rgb` channel variable (see
+ * colors.ts).
+ */
+export declare const lowerDeclarations: (rule: Rule, channelVariables?: ReadonlySet<string>) => LoweredRule;
+/**
+ * Lowers the values of the transform variables, once the variables in them
+ * are resolved (see variables.ts): `calc(0.25rem * 2)` folds to `0.5rem`.
+ */
+export declare const lowerTransformVariables: (root: Root) => void;

package/dist/tailwind-v4/declarations.test.d.ts

@@ -0,0 +1 @@
+export {};

package/dist/tailwind-v4/index.d.ts

@@ -0,0 +1,23 @@
+import type { PluginCreator, Root, Rule } from 'postcss';
+/**
+ * A PostCSS plugin that makes the CSS Tailwind CSS 4 writes work on Lynx. It
+ * runs after `@tailwindcss/postcss`, and only on the stylesheets Tailwind
+ * compiled, so every other stylesheet reaches Lynx as it was written.
+ *
+ * Tailwind 4 writes CSS for current browsers: cascade layers, `@property`,
+ * nesting, `oklch()` colors, `color-mix()`, logical properties and the
+ * individual `translate`/`rotate`/`scale` properties. Lynx reads none of
+ * them, and mostly drops them without a warning, while Lynx for Web passes
+ * them to the browser, so the web preview looks right and the app doesn't.
+ * Lynx's Tailwind preset avoids this for Tailwind 3 by changing the
+ * utilities; Tailwind 4 has no switch to turn its core utilities off, so this
+ * rewrites its output instead, into CSS with the same meaning that Lynx
+ * reads, on native and on the web alike. See
+ * investigations/lynx-vs-web-differences.md for what Lynx does with each.
+ */
+export declare const tailwindForLynx: PluginCreator<void>;
+/**
+ * Lowers a stylesheet Tailwind 4 compiled. `createRule` makes the rule that
+ * holds the variables' starting values.
+ */
+export declare const lowerForLynx: (root: Root, createRule: (selector: string) => Rule) => void;

package/dist/tailwind-v4/index.test.d.ts

@@ -0,0 +1 @@
+export {};

package/dist/tailwind-v4/lynx-properties.d.ts

@@ -0,0 +1,20 @@
+/**
+ * Every CSS property Lynx has, from the definitions its CSS engine is
+ * generated from (lynx-family/lynx, tools/css_generator/css_defines, as of
+ * October 2026). Add a property here when Lynx adds one.
+ *
+ * Tailwind CSS 4 has no way to turn a core utility off, and it generates
+ * every class it finds in the source, even a word in a string such as
+ * `uppercase`. Lynx drops a property it doesn't have, with a build warning,
+ * but Lynx for Web passes it to the browser, so the web preview would show
+ * styles the app never gets. Tailwind 3 avoided this with the Lynx preset's
+ * list of core plugins.
+ */
+export declare const LYNX_PROPERTIES: ReadonlySet<string>;
+/**
+ * The keywords each of Lynx's keyword-only properties takes, from the same
+ * definitions. Tailwind 4 writes values Lynx doesn't have for some of them
+ * (`display: inline`, `position: static`, `white-space: pre`), which Lynx drops and
+ * the web preview would apply; the Lynx preset left those utilities out.
+ */
+export declare const LYNX_KEYWORDS: ReadonlyMap<string, ReadonlySet<string>>;

package/dist/tailwind-v4/selectors.d.ts

@@ -0,0 +1,6 @@
+import type { Rule } from 'postcss';
+/**
+ * Rewrites the selectors Tailwind CSS 4 writes into ones Lynx matches.
+ * Returns `false` when no selector is left, so the caller removes the rule.
+ */
+export declare const lowerSelectors: (rule: Rule) => boolean;

package/dist/tailwind-v4/selectors.test.d.ts

@@ -0,0 +1 @@
+export {};

package/dist/tailwind-v4/structure.d.ts

@@ -0,0 +1,51 @@
+import type { Container, Root } from 'postcss';
+/**
+ * Unwraps the CSS structure Tailwind CSS 4 writes and Lynx can't read:
+ * nesting, `@layer` blocks and `@property` registrations.
+ */
+/**
+ * Moves nested rules and at-rules out to the top level, the way Sass does:
+ * `.a { &:hover { … } }` becomes `.a:hover { … }`, and
+ * `.a { @media (…) { … } }` becomes `@media (…) { .a { … } }`.
+ *
+ * Tailwind 4 writes its variants nested (`hover:`, `md:`, the `@supports`
+ * fallback of an opacity modifier). Lynx's CSS parser reads a nested rule as
+ * a descendant selector and never sees the `&`, and Lynx for Web throws on
+ * it, so neither applies them. A production build already arrives flattened
+ * (Tailwind minifies with Lightning CSS); a development build doesn't.
+ */
+export declare const flattenNesting: (root: Root) => void;
+/**
+ * Replaces every `@layer` block with its contents and drops `@layer`
+ * statements.
+ *
+ * Lynx ignores a rule inside `@layer`, on native and on the web, so none of
+ * Tailwind 4's CSS would apply. Tailwind writes its layers in cascade order
+ * (theme, base, components, utilities), so keeping the source order keeps
+ * the cascade between them.
+ */
+export declare const unwrapLayers: (container: Container) => void;
+/**
+ * Removes the `@property` registrations and returns the custom properties
+ * that have an initial value, with that value.
+ *
+ * Lynx has no `@property`, so a variable Tailwind registers with an initial
+ * value (`--tw-border-style: solid`, `--tw-translate-x: 0`) is unset until a
+ * utility sets it, and every value that reads it breaks: `border` draws no
+ * border. A registration without an initial value is left out on purpose: the
+ * variable stays unset, so the `var()` fallbacks Tailwind writes apply.
+ */
+export declare const takePropertyRegistrations: (root: Root) => Map<string, string>;
+/**
+ * Removes the rules and at-rules the steps above left empty, such as a
+ * nested rule's parent that held only nested rules.
+ */
+export declare const removeEmptyContainers: (container: Container) => void;
+/**
+ * Writes out the `from` and `to` keyframes an animation leaves implied.
+ *
+ * Lynx doesn't play an animation that lacks either, and Tailwind's `spin`
+ * has only `to`, `ping` no `from`, and `pulse` neither, so `animate-spin`
+ * did nothing on device.
+ */
+export declare const completeKeyframes: (root: Root) => void;

package/dist/tailwind-v4/structure.test.d.ts

@@ -0,0 +1 @@
+export {};

package/dist/tailwind-v4/variables.d.ts

@@ -0,0 +1,20 @@
+import type { Root } from 'postcss';
+/**
+ * Resolves the `var()` references that Lynx can't, inside the custom
+ * properties Tailwind CSS 4 sets.
+ *
+ * Lynx substitutes a `var()` that a custom property's value holds directly
+ * (`--tw-gradient-from: var(--color-red-500)`), but not one inside another
+ * function: `--tw-translate-x: calc(var(--spacing) * 2)` and
+ * `--tw-blur: blur(var(--blur-sm))` leave the property invalid, so the
+ * utility does nothing on device. That holds even when the variable is set
+ * in the same rule or the `var()` has a fallback.
+ *
+ * Each such reference becomes a value this stylesheet already knows: the
+ * variable's declaration in the same rule, else its theme value (the
+ * `:root` rule Tailwind writes), else the reference's fallback, else the
+ * initial value Tailwind registered with `@property`. Only a variable set by
+ * another utility on the same element, such as `ring-offset-2`'s width under
+ * `ring-2`, loses its effect, since the value is now fixed.
+ */
+export declare const resolveNestedVariables: (root: Root, registrations: ReadonlyMap<string, string>) => void;

package/dist/tailwind-v4/variables.test.d.ts

@@ -0,0 +1 @@
+export {};

package/dist/tailwind.d.ts

@@ -1,2 +1,16 @@
 import type { RsbuildPluginAPI } from '@lynx-js/rspeedy';
+/**
+ * Sets Tailwind CSS up for the app, either version:
+ *
+ * - **Tailwind 3** runs when the app has a `tailwind.config.*`, the way
+ *   Angular CLI sets it up. Its config uses `@lynx-js/tailwind-preset`.
+ * - **Tailwind 4** runs when the app's PostCSS config lists
+ *   `@tailwindcss/postcss` (`.postcssrc.json`, which `ng add` writes as
+ *   Angular CLI's own Tailwind setup does). Rsbuild loads that config itself.
+ *
+ * Either way, a PostCSS plugin added after Tailwind rewrites the CSS
+ * Tailwind 4 writes into CSS Lynx reads (see tailwind-v4/index.ts). It only
+ * touches the stylesheets Tailwind 4 compiled, so it adds nothing to a
+ * Tailwind 3 build or a build without Tailwind.
+ */
 export declare const applyTailwind: (api: RsbuildPluginAPI) => void;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blotch/rsbuild-plugin-angular-lynx",
-  "version": "22.2.3",
+  "version": "22.2.4",
   "description": "Rsbuild plugin for building AngularLynx applications",
   "homepage": "https://github.com/Blotch-Smart-Frames/AngularLynx#readme",
   "bugs": {
@@ -45,6 +45,7 @@
     "@lynx-js/runtime-wrapper-webpack-plugin": "^0.2.4",
     "@lynx-js/template-webpack-plugin": "^0.16.2",
     "@lynx-js/webpack-runtime-globals": "^0.0.8",
+    "postcss-value-parser": "^4.2.0",
     "tiny-invariant": "^1.3.3"
   },
   "devDependencies": {
@@ -53,7 +54,10 @@
     "@rsbuild/core": "^2.2.9",
     "@rslib/core": "^0.21.4",
     "@rspack/core": "^2.2.8",
+    "@tailwindcss/postcss": "^4.3.3",
     "@types/node": "^25.6.2",
+    "postcss": "^8.5.6",
+    "tailwindcss": "^4.3.3",
     "type-fest": "^5.6.0",
     "typescript": "^6.0.3"
   },