@s-ui/bundler 9.79.0-beta.3 → 9.79.0

package/README.md

@@ -184,6 +184,10 @@ This tool works with zero configuration out the box but you could use some confi
 
 `disableTypeScriptLoader`: Flag to determine if typescript loader should be used. (default: `false`)
 
+`plainCssPackages`: Array of npm package names whose `.css` files should bypass `@s-ui/sass-loader` and `postcss-loader`. Use this for packages that ship pre-compiled CSS (e.g. Tailwind CSS v4 output) that would cause Sass parse errors. (default: `[]`)
+
+`cssInAppStyles`: Array of npm package names whose CSS modules should be forced into the `AppStyles` chunk. This prevents webpack's `splitChunks` from extracting them into separate async chunks that `@s-ui/ssr` doesn't know about — avoiding Flash of Unstyled Content. (default: `[]`)
+
 ```json
 {
   "config": {
@@ -202,6 +206,8 @@ This tool works with zero configuration out the box but you could use some confi
         "dev": "cheap-module-eval-source-map",
         "prod": "hidden-source-map"
       },
+      "plainCssPackages": ["@adv-mt/ui", "@adv-mt/theme"],
+      "cssInAppStyles": ["@adv-mt/ui", "@adv-mt/theme"],
       "disableTypeScriptLoader": true // Only if you want to disable typescript loader
     }
   }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@s-ui/bundler",
-  "version": "9.79.0-beta.3",
+  "version": "9.79.0",
   "description": "Config-free bundler for ES6 React apps.",
   "bin": {
     "sui-bundler": "./bin/sui-bundler.js"

package/webpack.config.prod.js

@@ -74,7 +74,7 @@ const webpackConfig = {
     compression: false
   },
   plugins: cleanList([
-    ...plainCssSplitChunks().plugins || [],
+    ...(plainCssSplitChunks().plugins || []),
     new webpack.ProvidePlugin({
       process: 'process/browser.js'
     }),

package/docs/tailwind-v4-integration.md

@@ -1,71 +0,0 @@
-# Tailwind v4 integration in `@s-ui/bundler` — investigation & alternatives
-
-## Context
-
-- `@adv-mt/ui` (Milanuncios DS) ships Tailwind **v4** CSS via `@tailwindcss/postcss`.
-- `@adv-re/ui` (Fotocasa DS) uses Tailwind **v3**.
-- `@s-ui/bundler` (`9.78.0`) hard-pins `tailwindcss@3.4.14` and enables the plugin only when a `tailwind.config.js` file exists at the project root.
-- Tailwind v4 has an incompatible API: CSS-first config (`@import "tailwindcss"`, `@source`, `@theme`), no JS config by default, plugin renamed to `@tailwindcss/postcss`, built-in vendor prefixing.
-
-Relevant code: `packages/sui-bundler/shared/module-rules-sass.js`, `shared/index.js` (`isTailwindEnabled`), `webpack.config.dev.js`, `webpack.config.client.dev.js`.
-
-Relevant external work:
-- MA integration PR — `frontend-ma--web-app#7667`
-- Strategy doc — `frontend-ma--web-app/docs/design-system-css-strategy.md`
-- Bundler PR — [SUI-Components/sui#1988](https://github.com/SUI-Components/sui/pull/1988) (`plainCssPackages` config to bypass sass-loader for plain CSS packages)
-
-## Alternatives
-
-### A. Land #1988 (`plainCssPackages`) — patch release
-
-Bypass sass + postcss for pre-built DS CSS. No Tailwind upgrade.
-
-- Pros: zero risk for Fotocasa; unblocks MA today; small surface.
-- Cons: doesn't enable app-build Tailwind (Option 2 in MA's strategy doc); MA keeps shipping the full pre-built `@adv-mt/ui/styles.css`.
-
-### B. Peer-dep Tailwind — major (v10) — **recommended**
-
-Remove `tailwindcss` from bundler deps. Consumer installs `tailwindcss@3` OR `tailwindcss@4` + `@tailwindcss/postcss`. Bundler detects which is installed and wires the correct postcss plugin.
-
-- Pros: no forced migration; each team upgrades on its own schedule; future-proof; bundler owns no Tailwind bugs.
-- Cons: more setup for consumers (one extra install); detection logic in bundler.
-
-### C. Hard upgrade v3 → v4 — major (v10)
-
-Replace `tailwindcss@3` with `@tailwindcss/postcss@4`. Drop `tailwind.config.js` detection. Fotocasa migrates via `npx @tailwindcss/upgrade`.
-
-- Pros: clean, single path forward.
-- Cons: forces Fotocasa work; release coordination.
-
-### D. Dual-mode flag — major (v10)
-
-Ship both `tailwindcss@3` and `@tailwindcss/postcss@4`. Detect entry (`tailwind.config.js` → v3, `tailwind.css`/CSS-first → v4) and pick plugin per project. Remove v3 in v11.
-
-- Pros: smooth ramp; opt-in v4.
-- Cons (maintenance is moderate, not trivial):
-  - Two Tailwind deps shipped — bigger install for every consumer, even single-version ones.
-  - Branching pipeline lives in `module-rules-sass.js` + 3 webpack configs.
-  - Two doc paths in README.
-  - Test matrix doubles — every bundler release verified against v3 and v4.
-  - Bug surface: plugin order, autoprefixer overlap with v4's built-in prefixing, sourcemaps differ.
-  - Sunset still requires Fotocasa migration in v11 — work is deferred, not avoided.
-- Verdict: real cost is owning v3 bugs in sui-bundler for ~a year. Worse than B unless Fotocasa explicitly wants zero-effort upgrade.
-
-### E. Skip bundler change; push DS to per-component CSS exports
-
-Pair with #1988. DS publishes `@adv-mt/ui/button/styles.css` etc. Sidesteps v4-in-bundler entirely until both teams want app-build Tailwind.
-
-- Pros: no bundler v10 needed.
-- Cons: requires DS build changes; consumer tracks per-page imports; no automatic tree-shaking.
-
-## Recommendation
-
-1. **Now** — merge #1988, patch release. Unblocks MA today, zero risk to Fotocasa.
-2. **Next major (v10)** — option **B** (peer-dep). Best ergonomics across teams; lets each move independently; gives MA the path to app-build Tailwind v4 without forcing Fotocasa.
-3. **Fallback** if peer-dep complexity is too high → option **D**, drop v3 in v11.
-
-## Open questions
-
-- Does Fotocasa have appetite to migrate to v4 (with codemod) within v10's window? If yes, **C** becomes viable and simpler than B.
-- Are there other sui-bundler consumers using Tailwind v3? Audit before committing to B/C/D.
-- Does autoprefixer need to be removed/conditional under v4? v4 has built-in vendor prefixing.