# Wie Laravel mit JavaScript und CSS umgeht — und was das für uns heisst
Diese Doku beantwortet drei Fragen mit Blick auf einen **möglichen** (nicht
beschlossenen) Umzug auf Laravel: Wie kommen JS und CSS in Laravel auf die Seite?
Wird das gebündelt? Und was bedeutet das konkret für unsere frameworklose
`git-pull`-App?
Stand: Laravel 12.x / 13.x, Tailwind CSS v4, Vite 5+ (2025/2026). Sie ergänzt
[css-strategie.md](css-strategie.md) — dort steht die CSS-Namensstrategie und die
Durable-vs-Wegwerf-Abwägung (§5) — und
[frontend-abhaengigkeiten.md](frontend-abhaengigkeiten.md) — dort steht unser
heutiger „npm nur als Bezugsquelle, `dist/` committen"-Ansatz (§1). Diese Doku
schaut speziell auf **Asset-Verrohrung und Build-Pipeline**.
> **Umsetzungsstand** (siehe `CHANGELOG.md`): Von den unten als *durable* bewerteten
> Arbeiten sind bereits erledigt — Konsolidierung der neun `style.css` zu **einer**
> `css/app.css`, totes CSS entfernt, der zentrale `partials/head.php` mit lokal
> committetem `library/`. Die Vite-/Blade-/Tailwind-Aussagen bleiben unverändert:
> Sie beschreiben den *möglichen* Laravel-Weg, nicht den aktuellen Stand.
## Kurzantwort
**Ja, Laravel bündelt** — und zwar zwingend über **Vite** (seit Laravel 9.19 der
Default; Laravel Mix / Webpack sind Geschichte). Es gibt keinen unterstützten
„kein Build"-Weg mehr wie unseren heutigen. `npm run build` erzeugt aus
`resources/js` und `resources/css` minifizierte, tree-geshakete, inhaltsgehashte
Bundles in `public/build/`, plus eine `manifest.json`; im `` steht nur noch
`@vite([...])`, das im Dev auf den HMR-Server und im Prod auf die gehashten
Dateien zeigt. Für uns heisst das: Unser committetes `library/` ist eine **Brücke,
keine dauerhafte Investition** — ein Laravel-Umzug ersetzt es durch npm-Deps +
Vite-Bundle und bringt einen Build-Schritt in den Deploy. Was den Umzug
**überlebt**, ist Token-CSS, die konsolidierte `app.css`, entferntes totes CSS und
sprechende Komponenten-Namen; **Wegwerfarbeit** wäre die no-build-Verrohrung selbst
und schwere BEM-Bäume.
---
## 1. Laravels Standard-Mechanismus: Vite
### 1.1 Die Pipeline im Überblick
Laravel liefert seit Version 9.19 **Vite** als Standard-Bundler mit (davor Laravel
Mix auf Webpack-Basis — das ist der veraltete Stand, der in vielen älteren
Tutorials noch steht). Eine frische Laravel-App bringt Vite und eine fertige
`vite.config.js` bereits mit; man muss nichts zusätzlich aufsetzen.
Die Bestandteile:
| Teil | Rolle |
|---|---|
| `resources/js/app.js` | JS-Entry-Point. Importiert weitere Module per ES-`import`. |
| `resources/css/app.css` | CSS-Entry-Point. |
| `vite.config.js` | Konfiguriert Vite; deklariert die Entry-Points via `laravel-vite-plugin`. |
| `@vite([...])`-Blade-Directive | Bindet die Assets im `` ein — kontextabhängig Dev oder Prod. |
| `package.json` | npm-Abhängigkeiten (Vite, Plugins, Frontend-Libs). |
| `public/build/` | **Erzeugtes** Ausgabeverzeichnis der Production-Bundles (nicht ins Repo). |
Die typische `vite.config.js` einer Standard-App:
```js
import { defineConfig } from 'vite';
import laravel from 'laravel-vite-plugin';
export default defineConfig({
plugins: [
laravel([
'resources/css/app.css',
'resources/js/app.js',
]),
],
});
```
Im Layout-Blade steht dann nur noch:
```blade
{{-- ... --}}
@vite(['resources/css/app.css', 'resources/js/app.js'])
```
Das ersetzt unsere heutige Kette aus einzelnen ``/`