Vite 5.1 ist da!

8. Februar 2024

Vite 5 wurde im November letzten Jahres veröffentlicht und stellte einen weiteren großen Sprung für Vite und das Ökosystem dar. Vor einigen Wochen feierten wir 10 Millionen wöchentliche npm-Downloads und 900 Mitwirkende am Vite-Repo. Heute freuen wir uns, die Veröffentlichung von Vite 5.1 bekannt zu geben.

Schnellzugriff: Dokumentation, Änderungsprotokoll

Dokumentation in anderen Sprachen: 简体中文, 日本語, Español, Português, 한국어, Deutsch

Probieren Sie Vite 5.1 online in StackBlitz aus: vanilla, vue, react, preact, lit, svelte, solid, qwik.

Wenn Sie Vite noch nicht kennen, empfehlen wir Ihnen, zunächst die Anleitungen Erste Schritte und Funktionen zu lesen.

Um auf dem Laufenden zu bleiben, folgen Sie uns auf X oder Mastodon.

Vite-Laufzeit-API

Vite 5.1 bietet experimentelle Unterstützung für eine neue Vite-Laufzeit-API. Damit kann beliebiger Code ausgeführt werden, indem er zunächst mit Vite-Plugins verarbeitet wird. Der Unterschied zu server.ssrLoadModule besteht darin, dass die Laufzeitimplementierung vom Server entkoppelt ist. Dadurch können Autoren von Bibliotheken und Frameworks ihre eigene Kommunikationsebene zwischen Server und Laufzeit implementieren. Diese neue API soll die aktuellen SSR-Primitive von Vite ersetzen, sobald sie stabil läuft.

Die neue API bietet viele Vorteile:

• Unterstützung für HMR während SSR.
• Sie ist vom Server entkoppelt, sodass es keine Begrenzung hinsichtlich der Anzahl der Clients gibt, die einen einzelnen Server nutzen können – jeder Client verfügt über einen eigenen Modul-Cache (Sie können sogar nach Belieben mit ihm kommunizieren – über einen Nachrichtenkanal/Fetch-Aufruf/direkten Funktionsaufruf/Websocket).
• Sie ist nicht von integrierten APIs von Node/Bun/Deno abhängig, sodass sie in jeder Umgebung ausgeführt werden kann.
• Sie lässt sich leicht in Tools integrieren, die über einen eigenen Mechanismus zum Ausführen von Code verfügen (Sie können beispielsweise einen Runner bereitstellen, der eval anstelle von new AsyncFunction verwendet).

Die ursprüngliche Idee wurde von Pooya Parsa vorgeschlagen und von Anthony Fu als [vite-node](https://github.com/vitest-dev/vitest/tree/main/packages/vite-node# readme) implementiert, um Nuxt 3 Dev SSR zu unterstützen, und später auch als Grundlage für Vitest verwendet. Die Grundidee von vite-node hat sich also bereits seit geraumer Zeit in der Praxis bewährt. Es handelt sich hierbei um eine neue Iteration der API von Vladimir Sheremet, der vite-node bereits in Vitest neu implementiert hatte und die gewonnenen Erkenntnisse nutzte, um die API noch leistungsfähiger und flexibler zu gestalten, als er sie zu Vite Core hinzufügte. Die PR war ein Jahr in der Entwicklung. Die Entwicklung und die Diskussionen mit den Betreuern des Ökosystems können Sie hier nachlesen.

Funktionen

Verbesserte Unterstützung für .css?url

Das Importieren von CSS-Dateien als URLs funktioniert nun zuverlässig und korrekt. Dies war die letzte verbleibende Hürde bei der Umstellung von Remix auf Vite. Siehe (#15259).

build.assetsInlineLimit unterstützt jetzt einen Callback

Benutzer können jetzt einen Callback bereitstellen, der einen booleschen Wert zurückgibt, um das Inlining für bestimmte Assets zu aktivieren oder zu deaktivieren. Wenn undefined zurückgegeben wird, gilt die Standardlogik. Siehe (#15366).

Verbessertes HMR für zirkuläre Importe

In Vite 5.0 lösten akzeptierte Module innerhalb zirkulärer Importe immer eine vollständige Neuladung der Seite aus, selbst wenn sie im Client problemlos verarbeitet werden konnten. Dies wurde nun gelockert, sodass HMR ohne vollständiges Neuladen der Seite angewendet werden kann. Wenn jedoch während HMR ein Fehler auftritt, wird die Seite neu geladen. Siehe (#15118).

Unterstützung von ssr.external: true zur Externalisierung aller SSR-Pakete

Bisher externalisiert Vite alle Pakete mit Ausnahme von verknüpften Paketen. Mit dieser neuen Option können Sie die Externalisierung aller Pakete, einschließlich verknüpfter Pakete, erzwingen. Dies ist praktisch bei Tests innerhalb von Monorepos, bei denen wir den üblichen Fall aller externalisierten Pakete emulieren möchten, oder wenn wir ssrLoadModule zum Laden einer beliebigen Datei verwenden und wir immer externe Pakete verwenden möchten, da uns HMR nicht interessiert. Siehe (#10939).

close-Methode im Preview-Server verfügbar machen

Der Preview-Server stellt nun eine close-Methode zur Verfügung, die den Server einschließlich aller geöffneten Socket-Verbindungen ordnungsgemäß herunterfährt. Siehe (#15630).

Leistungsverbesserungen

Vite wird mit jeder neuen Version schneller, und Vite 5.1 bietet zahlreiche Leistungsverbesserungen. Wir haben die Ladezeit für 10.000 Module (25 Ebenen tiefe Baumstruktur) mit vite-dev-server-perf für alle Minor-Versionen ab Vite 4.0 gemessen. Dies ist ein guter Maßstab, um die Auswirkungen des bundle-losen Ansatzes von Vite zu messen. Jedes Modul ist eine kleine TypeScript-Datei mit einem Zähler und Importen zu anderen Dateien in der Baumstruktur, sodass hier hauptsächlich die Zeit gemessen wird, die für die Anfragen an separate Module benötigt wird. In Vite 4.0 dauerte das Laden von 10.000 Modulen auf einem M1 MAX 8 Sekunden. In Vite 4.3, wo wir uns auf die Leistung konzentriert haben, gelang uns ein Durchbruch, und wir konnten sie in 6,35 Sekunden laden. In Vite 5.1 gelang uns ein weiterer Leistungssprung. Vite bedient die 10.000 Module nun in 5,35 Sekunden.

Die Ergebnisse dieses Benchmarks wurden mit Headless Puppeteer durchgeführt und eignen sich gut zum Vergleich der Versionen. Sie geben jedoch nicht die Zeit wieder, die Benutzer tatsächlich erleben. Wenn wir dieselben 10K-Module in einem Inkognito-Fenster in Chrome ausführen, erhalten wir:

10K Module	Vite 5.0	Vite 5.1
Ladezeit	2892ms	2765ms
Ladezeit (cached)	2778ms	2477ms
Vollständiges Neuladen	2003ms	1878ms
Vollständiges Neuladen (cached)	1682ms	1604ms

CSS-Präprozessoren in Threads ausführen

Vite bietet nun eine optionale Unterstützung für die Ausführung von CSS-Präprozessoren in Threads. Sie können diese Funktion mit css.preprocessorMaxWorkers: true aktivieren. Bei einem Vuetify 2-Projekt konnte die Startzeit für Entwickler mit dieser Funktion um 40 % reduziert werden. Es gibt einen Leistungsvergleich für andere Setups im PR. Siehe (#13584). Feedback geben.

Neue Optionen zur Verbesserung von Server-Kaltstarts

Sie können optimizeDeps.holdUntilCrawlEnd: false einstellen, um zu einer neuen Strategie für die Deps-Optimierung zu wechseln, die bei großen Projekten hilfreich sein kann. Wir erwägen, in Zukunft standardmäßig zu dieser Strategie zu wechseln. Feedback geben. (#15244)

Schnellere Auflösung mit zwischengespeicherten Prüfungen

Die Optimierung fs.cachedChecks ist jetzt standardmäßig aktiviert. Unter Windows war tryFsResolve damit etwa 14-mal schneller, und die Auflösung von IDs wurde im Dreiecks-Benchmark insgesamt um etwa das Fünffache beschleunigt. (#15704)

Interne Leistungsverbesserungen

Der Dev-Server hat mehrere inkrementelle Leistungssteigerungen erfahren. Eine neue Middleware für Kurzschlüsse bei 304 (#15586). Wir haben parseRequest in Hot Paths vermieden (#15617). Rollup wird nun ordnungsgemäß verzögert geladen (#15621).

Veraltete Funktionen

Wir reduzieren weiterhin die API-Oberfläche von Vite, wo immer dies möglich ist, um das Projekt langfristig wartbar zu halten.

Veraltete Option as in import.meta.glob

Der Standard wurde zu Import Attributes verschoben, aber wir planen derzeit nicht, as durch eine neue Option zu ersetzen. Stattdessen wird empfohlen, dass der Benutzer zu query wechselt. Siehe (#14420).

Experimentelles Vorab-Bündeln zur Build-Zeit entfernt

Das Vorab-Bündeln zur Build-Zeit, eine in Vite 3 hinzugefügte experimentelle Funktion, wurde entfernt. Da Rollup 4 seinen Parser auf nativ umgestellt hat und an Rolldown gearbeitet wird, sind sowohl die Leistung als auch die Inkonsistenz zwischen Entwicklung und Build für diese Funktion nicht mehr gültig. Wir möchten die Konsistenz zwischen Entwicklung und Build weiter verbessern und sind zu dem Schluss gekommen, dass die Verwendung von Rolldown für Vorab-Bündelung während der Entwicklung und Produktions-Builds die bessere Wahl für die Zukunft ist. Rolldown kann auch Caching auf eine Weise implementieren, die während des Builds viel effizienter ist als das Vorab-Bündeln von Abhängigkeiten. Siehe (#15184).

Mitmachen

Wir sind den 900 Mitwirkenden an Vite Core sowie den Betreuern von Plugins, Integrationen, Tools und Übersetzungen, die das Ökosystem vorantreiben, sehr dankbar. Wenn Ihnen Vite gefällt, laden wir Sie ein, sich zu beteiligen und uns zu helfen. Lesen Sie unseren Beitragsleitfaden und steigen Sie ein, indem Sie Probleme triagieren, PRs zu überprüfen, Fragen in GitHub-Diskussionen zu beantworten und anderen in der Community in Vite Land zu helfen.

Danksagungen

Vite 5.1 wurde dank unserer Community von Mitwirkenden, Betreuern im Ökosystem und dem Vite-Team möglich. Ein großes Dankeschön an die Personen und Unternehmen, die die Entwicklung von Vite sponsern. StackBlitz, Nuxt Labs und Astro für die Einstellung von Vite-Teammitgliedern. Und auch an die Sponsoren auf Vites GitHub Sponsors, Vites Open Collective und Evan Yous GitHub Sponsors.