Das Vite-Team gab offiziell bekannt, dass Vite 5.1 offiziell eingeführt wurde .
Vite (französisch für „schnell“, ausgesprochen
/vit/wie „veet“) ist ein neues Front-End-Erstellungstool, das die Front-End-Entwicklungserfahrung erheblich verbessert. Es besteht im Wesentlichen aus zwei Teilen:
Ein Entwicklungsserver, der umfangreiche integrierte Funktionen basierend auf nativen ES-Modulen bietet, wie z. B. ein unglaublich schnelles Hot Module Update (HMR).
Eine Reihe von Build-Anweisungen, die Rollup zum Packen Ihres Codes verwenden und vorkonfiguriert sind, um hochoptimierte statische Ressourcen für Produktionsumgebungen auszugeben.
Vite bietet leistungsstarke Erweiterbarkeit durch seine Plug-in-API und JavaScript-API und bietet vollständige Typunterstützung.
Vite-Laufzeit-API
Vite 5.1 bietet experimentelle Unterstützung für die neue Vite Runtime API. Damit kann jeder Code zuerst mit dem Vite-Plugin verarbeitet und dann ausgeführt werden. Dies ist server.ssrLoadModuleein großer Unterschied, da die Laufzeitimplementierung vom Server entkoppelt ist. Dadurch können Bibliotheks- und Framework-Autoren ihre eigene Kommunikationsschicht zwischen dem Server und der Laufzeit implementieren. Die neue Vite Runtime API soll nach der Stabilisierung die aktuellen SSR-Primitive (serverseitige Rendering-Primitive) von Vite ersetzen.
Die neue Vite Runtime API bringt viele Vorteile für das Jahr des Drachen:
-
Unterstützen Sie HMR (Hot Module Replacement) während der SSR
-
Es ist vom Server entkoppelt, sodass die Anzahl der Clients, die einen einzelnen Server verwenden können, unbegrenzt ist. Jeder Client verfügt über einen eigenen Modulcache und wir können sogar nach unseren persönlichen Vorlieben mit ihm kommunizieren, einschließlich, aber nicht beschränkt auf Verwenden von Nachrichtenkanälen/
fetchAufrufen/direktem Funktionsaufruf/Websocket. -
Es ist nicht auf eine
node/bun/denointegrierte API angewiesen und kann daher in jeder Umgebung ausgeführt werden. -
evalEs kann problemlos in Tools integriert werden, die über einen eigenen Mechanismus zum Ausführen von Code verfügen. Beispielsweise können wir stattdessen einen Runner bereitstellennew AsyncFunction.
Die ursprüngliche Idee wurde von PP vorgeschlagen und vite-nodevon AntFu als Paket implementiert, das Nuxt 3 Dev SSR antrieb und später als Infrastruktur von Vitest diente. Daher vite-nodehat das Gesamtdenken den Langzeittest „Code aus der Ferne kennen“ bestanden. Dies ist eine neue Iteration der API in VS. Sie wurde in Vitest reproduziert vite-nodeund hat ihre Vergangenheit durch die Integration in die Vite-Kernbibliothek geändert, wodurch die Vite Runtime API flexibler und leistungsfähiger wird. Auf diesen PR (Pull Request) hat man ein ganzes Jahr gewartet.
Funktion
Verbesserte .css?urlUnterstützung
Das Importieren von CSS-Dateien als URLs funktioniert jetzt erfolgreich. Dies ist das letzte Hindernis bei der Migration von Remix zu Vite.
build.assetsInlineLimitRückrufe werden jetzt unterstützt
Benutzer können jetzt eine Rückruffunktion bereitstellen, die einen booleschen Wert zurückgibt, um Inlining für eine bestimmte Ressource zu aktivieren oder zu deaktivieren. Bei Rückgabe undefinedwird die Standardlogik angewendet.
Verbessertes HMR für Schleifenimporte
In Vite 5.0 lösen Module, die in zirkulären Importen akzeptiert werden, immer einen vollständigen Neuladen der Seite aus, auch wenn sie auf der Clientseite ordnungsgemäß verarbeitet werden können. Dieses Problem wurde nun behoben, sodass HMR angewendet werden kann, ohne dass die gesamte Seite neu geladen werden muss. Wenn jedoch während HMR Fehler auftreten, wird die Seite neu geladen.
Unterstützt ssr.external: truedie Externalisierung aller SSR-Pakete
In der Vergangenheit hat Vite alle Pakete außer verknüpften Paketen externalisiert. Mit dieser brandneuen ssr.external: trueOption kann die Externalisierung aller Pakete, einschließlich verknüpfter Pakete, erzwungen werden. Dies ist praktisch bei Monorepos-Tests (Entwicklung mit mehreren Bibliotheken), bei denen wir den gemeinsamen Fall aller externen Pakete simulieren möchten, oder wenn ssrLoadModulebeliebige Dateien verwendet werden und wir immer externe Pakete verwenden möchten, weil uns HMR egal ist.
closeStellen Sie Methoden auf dem Vorschauserver bereit
Der Vorschauserver stellt jetzt eine closeMethode zur Verfügung, die den Server einschließlich aller offenen Socket-Verbindungen ordnungsgemäß herunterfährt.
Leistungsoptimierung
Vite wird mit jeder Veröffentlichung schneller und Vite 5.1 steckt voller Leistungsoptimierungen. Wir haben die Ladezeit eines 10K-Moduls (Ebenentiefenbaum) vite-dev-server-perfmit allen Nebenversionen von Vite seit Vite 4.0 gemessen. 25Dies ist ein hervorragender Maßstab, um die Wirksamkeit der unverpackten Lösung von Vite zu messen. Jedes Modul ist eine Mini-TS-Datei, die Zähler und Importe in andere Dateien im Modulbaum überträgt, sodass hier hauptsächlich der Zeitaufwand für die Ausführung von Anforderungen an einzelne Module gemessen wird. Bei Vite 4.0 dauert es 8Sekunden, ein 10K-Modul auf einen dünnen und leichten Gaming-Laptop zu laden. Mit dem leistungsorientierten Vite 4.3 sind wir sogar noch besser und können 6.35sie in Sekundenschnelle laden. Mit Vite 5.1 ist uns ein weiterer Leistungssprung gelungen. Vite kann jetzt 5.3510.000 Module in Sekundenschnelle bedienen.
Die Ergebnisse dieses Benchmarks werden auf Headless Puppeteer ausgeführt, einer hervorragenden Lösung für das Versions-Benchmarking. Sie spiegeln jedoch nicht die Länge der Benutzererfahrung wider. Wenn die gleiche Anzahl von 10K-Modulen in einem Inkognito-Fenster in Chrome ausgeführt wird, sieht es so aus:
| 10.000 Module | Schnell 5.0 | Schnell 5.1 |
|---|---|---|
| Ladezeit | 2892 ms | 2765 ms |
| Ladezeit (Cache) | 2778 ms | 2477 ms |
| Vollständiges Nachladen | 2003 ms | 1878 ms |
| Vollständiges Neuladen (Cache) | 1682 ms | 1604 ms |
Führen Sie den CSS-Präprozessor im Thread aus
Vite unterstützt jetzt optional die Ausführung von CSS-Präprozessoren in Threads. Wir können css.preprocessorMaxWorkers: truees mit aktivieren. Bei Vuetify 2-Projekten sank die Startzeit der Entwicklung nach der Aktivierung dieser Funktion um 40 %.
Neue Optionen zur Verbesserung des Server-Kaltstarts
optimizeDeps.holdUntilCrawlEnd: falseWir können einen Wechsel zu einer neuen Art von Abhängigkeitsoptimierungsstrategie einrichten , was bei größeren Projekten hilfreich sein kann. Wir erwägen, in Zukunft standardmäßig auf diese Richtlinie umzustellen.
Cache-Prüfungen für schnelleres Parsen
fs.cachedChecksDie Optimierung ist jetzt standardmäßig aktiviert. Unter Windows tryFsResolveist die Geschwindigkeit um etwa 14100 % gestiegen, und das Parsen von IDs im Dreieck-Benchmark ist 5insgesamt um etwa 100 % gestiegen.
Interne Leistungsoptimierung
Die Leistung des Entwicklungsservers wurde in mehreren Schritten verbessert. Eine neue Art von Middleware kann auf 304 einen Kurzschluss verursachen. Wir meiden heiße Wege parseRequest. Rollup wird jetzt korrekt Lazy Loaded.
Veraltete Funktionalität
Wir werden die API-Schnittstellen von Vite weiterhin minimieren, damit Vite langfristig aufrechterhalten werden kann.
Veraltete Optionen import.meta.glob_as
Der Standard wurde auf import Attributes(Eigenschaften importieren) verschoben, aber wir planen derzeit nicht, ihn durch die neue Option zu ersetzen as. Stattdessen empfehlen wir Benutzern, zu zu wechseln query.
Die experimentelle Vorverpackung zur Build-Zeit wurde entfernt
Das Vorverpacken zur Build-Zeit war eine experimentelle Funktion, die in Vite 3 hinzugefügt wurde und nun entfernt wurde. Da Rollup 4 seinen Parser auf nativ umstellt und Rolldown sich in der Entwicklung befindet, funktionieren sowohl die Leistung als auch die Entwicklungs- und Build-Inkonsistenzen dieser Funktion nicht mehr. Wir hoffen, die Entwicklungs-/Build-Konsistenz weiter verbessern zu können und sind zu dem Schluss gekommen, dass die Verwendung von Rolldown für „Vorverpackungen zur Entwicklungszeit“ und „Produktions-Builds“ eine bessere Wahl ist. Rolldown implementiert möglicherweise auch Caching zur Build-Zeit, was effizienter ist als die Verwendung von Vorpaketen.