<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Label this issue](https://contributors.gitlab.com/manage-issue?action=label&projectId=278964&issueIid=604394) </details> <!--IssueSummary end--> Bring CSS compilation into the Rspack build as a bundler-integrated step, so Rspack owns the full asset pipeline (JS + CSS) instead of CSS running as a separate pre-build. This mirrors what the Vite migration did for CSS. ## Current state Today CSS does **not** go through the bundler — it is a separate build step that runs *before* the bundler: - **App stylesheets** (`app/assets/stylesheets/**`, including `page_bundles/**`, `themes`, `mailers`, `highlight`, etc.) are compiled by `scripts/frontend/build_css.mjs` → `scripts/frontend/lib/compile_css.mjs`, which uses the `sass` compiler + PostCSS (autoprefixer, custom-properties, color-to-hex for mailers) and writes plain `.css` into `app/assets/builds/` (`yarn build:css`). - **Tailwind** is built by `scripts/frontend/tailwindcss.cjs` into `app/assets/builds/tailwind.css` (`yarn tailwindcss:build`) and `tailwind_cqs.css` (`yarn tailwindcss:cqs:build`, with `USE_TAILWIND_CONTAINER_QUERIES=true`). - `lib/tasks/gitlab/assets.rake` wires the `:tailwind` task as a **prerequisite of `compile`** (`task compile: :tailwind`), so Tailwind builds *before* `yarn build` (the bundler) ever runs. - `app/assets/builds/` is added as the highest-precedence Sprockets asset path (`config/application.rb`), and the compiled CSS is served by Sprockets via `stylesheet_link_tag` — the non-Vite branch of `universal_stylesheet_link_tag` (`app/helpers/vite_helper.rb`). So under Webpack/Rspack, CSS is a Sprockets concern, fully outside the bundler. - In dev, `scripts/frontend/webpack_dev_server.js` runs `compile_css.mjs` and `tailwindcss.cjs` as nodemon plugins (their own watchers) alongside the bundler dev server. What Rspack handles today is **only CSS imported from JS modules**: `config/rspack/loader_rules.js` has `style-loader`/`css-loader`/`sass-loader` rules for `.css`/`.scss`, with `experiments.css: false` and a `LightningCssMinimizerRspackPlugin` in `config/rspack.config.mjs`. This does **not** cover the standalone app stylesheets or Tailwind, which remain the separate step above. ## Proposed change Make CSS a first-class Rspack output, removing the separate pre-build, mirroring the Vite precedent: - **Tailwind** → run through Rspack via `postcss-loader` (Tailwind v3 as a PostCSS plugin), including the container-queries variant (`tailwind_cqs`), instead of `tailwindcss.cjs`. - **App stylesheets / page_bundles** → expose each SCSS entry (`application`, `application_dark`, `page_bundles/*`, themes, mailers, highlight, …) as a Rspack CSS entry, compiled with `sass-loader` + the existing PostCSS chain and emitted via `CssExtractRspackPlugin`. This is the equivalent of Vite's `StylePlugin` + `viteTailwindCompilerPlugin` (`config/helpers/vite_plugin_style.mjs`, `scripts/frontend/tailwindcss.cjs`), which provide virtual SCSS/Tailwind entrypoints resolved against the same load paths (`resolveLoadPaths`) and the same EE/JH precedence logic. - **Minification** uses the `LightningCssMinimizerRspackPlugin` already configured. - Update the Rails view layer so `universal_stylesheet_link_tag` / `add_page_specific_style` resolve CSS through the Rspack manifest when Rspack owns CSS, the way they already route through the Vite manifest when `vite_enabled?` — rather than through Sprockets `app/assets/builds/`. - Drop the separate `build:css` / `tailwindcss:build` / `tailwindcss:cqs:build` steps and the `task compile: :tailwind` prerequisite from the build path (and the nodemon CSS plugins from the dev server) once Rspack covers them. ### Vite precedent (reference) Vite moved CSS *inline into the bundler* for dev/serve: `vite.config.js` registers `StylePlugin` (virtual SCSS entrypoints) and `viteTailwindCompilerPlugin`, and `universal_stylesheet_link_tag` resolves CSS via the Vite manifest when Vite is enabled. Note Vite did **not** fully delete the standalone path: `vite-prod` still runs `yarn tailwindcss:build && yarn tailwindcss:cqs:build` before `vite build`, and the Tailwind/SCSS helpers in `scripts/frontend/` are shared by both pipelines. So the precedent is "bundler-integrated CSS entrypoints + manifest-driven serving," with some shared SCSS/Tailwind plumbing retained. This issue should be accurate about that: the goal is parity with the Vite integration model, reusing the existing `compile_css.mjs`/`tailwindcss.cjs` helpers where practical rather than rewriting them. ## Considerations / risks - **FOUC / load order**: app CSS is currently render-blocking `<link>` tags from Sprockets; CSS emitted by Rspack must preserve render-blocking behavior and ordering, not arrive via JS injection. - **Output filenames + manifest**: Rails helpers (`universal_stylesheet_link_tag`, `add_page_specific_style`, Sprockets fallback) expect specific names/paths; emitted CSS must be resolvable through the manifest with matching entry names, including the EE/JH precedence the current resolver encodes. - **Tailwind container-queries variant**: the `tailwind_cqs` build (`USE_TAILWIND_CONTAINER_QUERIES=true`, `tailwind_cqs.config.js`) and the `paneled_view`/container-query migration must keep working; `tailwindcss.cjs` has a brittle module-cache hack to run two Tailwind processors — re-evaluate under a loader-based setup. - **page_bundles side-effect check**: `scripts/frontend/check_page_bundle_mixins_css_for_sideeffects.js` (invoked from the compile task) must continue to guard against class definitions leaking from the mixins file. - **Sprockets interplay**: `app/assets/builds/` is the highest-precedence Sprockets path; moving CSS into Rspack must not strand Sprockets-served CSS or non-Rspack consumers (e.g. mailers, error pages, component previews). - **Parity verification**: diff emitted CSS against the current `app/assets/builds/` output (per entry) before/after to confirm no rule/order regressions. ## Scope - Compile Tailwind + app stylesheets through Rspack and serve them via the Rspack manifest; retire the separate CSS pre-build from the Rspack path. ### Out of scope - The Webpack and Vite CSS paths (Webpack stays in-tree but inactive; Vite's CSS glue stays dormant — both handled in their own epic issues). - Restructuring the SCSS sources themselves or the Tailwind v3→v4 upgrade. Depends on the switch to Rspack.