Description
Add an opt-in Tailwind CSS option for custom client JS (src/main/web) views, generated at build time without Node — by resolving the Tailwind standalone binary the same way the build already resolves the esbuild binary (an os-matched, checksummed native executable; not the npm/Node toolchain).
Proposed shape:
- A build option (off by default, e.g.
tailwind=true) runs the Tailwind standalone binary over src/main/web, scanning class usage, and emits one app-wide utilities stylesheet to web/.compiled/. It is then auto-loaded with the compiled bundles (the same mechanism that auto-loads compiled CSS).
- Prefer Tailwind v4 (CSS-first config): the input is a small CSS file (
@import "tailwindcss" + @source "./**/*.{js,jsx,ts,tsx}"), so there is no tailwind.config.js — a better fit for the no-Node, Maven-resolved model.
- Scoping (important): ship utilities only, with Preflight (the global CSS reset) disabled by default — Preflight would restyle the platform's own UI. Offer an optional utility class prefix for extra collision safety.
- Limits: only static class strings are detected (dynamically built names like
`bg-${x}` are not); the generated stylesheet's load order must be deterministic.
Keeps the platform's "native esbuild binary, no Node at build" promise.
Reason
Tailwind is the dominant utility-first styling approach in modern React and the main remaining styling gap for custom React views. It matters most for two cases: teams standardized on Tailwind, and Tailwind-based component libraries (shadcn/ui-style). It is also relevant for AI-generated UIs — LLMs are highly fluent in Tailwind. Static fixed-CSS frameworks (e.g. Bootstrap) already work today by loading their stylesheet via onWebClientInit; only build-time-generated frameworks (Tailwind/UnoCSS) are missing. Estimated effort is small-to-medium (a standalone-binary resolver + one build invocation + the no-preflight scoping policy + docs).
Description
Add an opt-in Tailwind CSS option for custom client JS (
src/main/web) views, generated at build time without Node — by resolving the Tailwind standalone binary the same way the build already resolves the esbuild binary (an os-matched, checksummed native executable; not the npm/Node toolchain).Proposed shape:
tailwind=true) runs the Tailwind standalone binary oversrc/main/web, scanning class usage, and emits one app-wide utilities stylesheet toweb/.compiled/. It is then auto-loaded with the compiled bundles (the same mechanism that auto-loads compiled CSS).@import "tailwindcss"+@source "./**/*.{js,jsx,ts,tsx}"), so there is notailwind.config.js— a better fit for the no-Node, Maven-resolved model.`bg-${x}`are not); the generated stylesheet's load order must be deterministic.Keeps the platform's "native esbuild binary, no Node at build" promise.
Reason
Tailwind is the dominant utility-first styling approach in modern React and the main remaining styling gap for custom React views. It matters most for two cases: teams standardized on Tailwind, and Tailwind-based component libraries (shadcn/ui-style). It is also relevant for AI-generated UIs — LLMs are highly fluent in Tailwind. Static fixed-CSS frameworks (e.g. Bootstrap) already work today by loading their stylesheet via
onWebClientInit; only build-time-generated frameworks (Tailwind/UnoCSS) are missing. Estimated effort is small-to-medium (a standalone-binary resolver + one build invocation + the no-preflight scoping policy + docs).