Vite+ 1.0 fasst sieben JS-Tools in einem Befehl zusammen. Wann sich dieser Tausch lohnt.

VoidZero hat Vite+ 1.0 am 28. September veröffentlicht – zeitgleich mit der Birthday Week von Cloudflare. Das Konzept ist einfach: ein Befehl, vp, und eine vite.config.ts, anstelle des Werkzeugstapels, den ein normales JavaScript-Projekt mit sich schleppt. Eine einzige vite-plus-Abhängigkeit ersetzt Vite, Vitest, einen Linter, einen Formatter, einen Git-Hook-Runner, einen Task-Runner und einen Node-Versionsmanager. Die Befehle bedeuten in jedem Repository dasselbe: vp dev, vp check, vp test, vp build, vp run. Das Release steht unter der MIT-Lizenz, nähert sich zwei Millionen wöchentlichen Downloads und wurde bereits in mehr als 2.600 öffentliche Repositories integriert.

Unter der Haube bündelt es Vite 8, Vitest 5, Rolldown, Oxlint und Oxfmt, mit eingebautem Task-Caching. Der Linter und der Formatter sind in Rust geschrieben, sodass die Prüfungen schnell sind. VoidZeros eigene Zahlen beziffern Oxlint auf 50 bis 100 Mal schneller als ESLint und Oxfmt bis zu 30 Mal schneller als Prettier. Vitest 5 ist bis zu 50% schneller als Vitest 4, und der Oxc React Compiler läuft etwa 10 Mal schneller als das Babel-Plugin, das er ersetzt. Cloudflare, das nun VoidZero besitzt, hat die Geschwindigkeitsverbesserungen rund um einen Gedanken gestellt, der es wert ist, innezuhalten: Coding-Agenten stehen still, während Ihre Toolchain mahlt – sobald die Inferenz schnell wird, werden Typprüfung und Linting zum Engpass.

Hier ist unsere ehrliche Einschätzung. Der Gewinn ist real, und er dreht sich hauptsächlich nicht um die Tipparbeit, die Sie sich sparen.

Was es tatsächlich beseitigt, ist Drift

Wenn wir cloud-native Apps für Unternehmenskunden entwickeln, liegt das langsame Lecken nie an einem defekten Tool. Es liegt an den Lücken zwischen den Tools. Die ESLint-Version auf dem Laptop eines Entwicklers, die nicht die in CI ist. Die Prettier-Konfiguration, die auf zwei Rechnern unterschiedlich formatiert. Die Node-Version, die niemand gepinnt hat. Das sind kleine Probleme, und kleine Probleme, die sich über ein Dutzend Repositories und einige hundert Builds wiederholen, werden teuer. Vite+ testet seinen Stack als eine Einheit und aktualisiert ihn als eine Einheit. Das ist der Teil, der sich auszahlt.

Dieselbe Eigenschaft ist auch der Haken – also gehen Sie mit offenen Augen vor. Sie upgraden, wenn Vite+ upgradet. Sie tauschen einen Cluster von Konfigurationen, den Sie kontrollieren, gegen die Standardeinstellungen eines Anbieters. Für ein neues Projekt ist das ein klares Ja. Für eine etablierte Codebasis mit einem sorgfältig abgestimmten ESLint-Regelwerk ist die eigentliche Frage, ob Oxlint die Regeln abdeckt, auf die Sie sich verlassen – und der Launch beantwortet das für Ihre spezifische Einrichtung nicht.

Was wir einem Team diese Woche raten würden

• Starten Sie etwas Neues? Führen Sie vp create aus und überspringen Sie die Woche, die Sie sonst mit dem Einrichten von Lint, Format, Test und CI verbringen würden. Die Standardeinstellungen sind vernünftig.
• Haben Sie ein bestehendes Projekt? Reißen Sie nichts mitten im Sprint heraus. Führen Sie vp migrate auf einem Branch aus. Es gibt seinen Plan aus, bevor es eine Datei anfasst – diff Sie diesen Plan, führen Sie Ihre vollständige Test-Suite dagegen aus und entscheiden Sie erst dann.
• Pinnen Sie die vite-plus-Version und lassen Sie CI – nicht einzelne Laptops – die Wahrheitsquelle für die Toolchain sein. Diese eine Gewohnheit räumt die meisten „läuft nur auf meinem Rechner"-Tickets aus dem Weg.

Der Sicherheitsaspekt, den viele übersehen

Eine Abhängigkeit, die sieben ersetzt, bedeutet eine kleinere Angriffsfläche und ein kürzeres Audit. Bei unseren Pentesting-Engagements und Dependency-Reviews ist der lange Schwanz transitiver Dev-Abhängigkeiten ein wiederkehrender Schwachpunkt: nicht gewartete Plugins, aufgegebene Formatter, ein Git-Hook-Paket, das seit drei Jahren niemand mehr geöffnet hat. Die Konsolidierung auf eine überprüfte, gut finanzierte Toolchain hilft hier – solange Sie diese einzelne Abhängigkeit als kritisch behandeln und sie gepatcht halten. Konzentration hat zwei Seiten: Ein Bug in der Sache, auf die jetzt alle angewiesen sind, erreicht alle auf einmal.

Der Gedanke gilt auch jenseits des Webs. Bei unserer nativen iOS- und Android-Entwicklung hat der Schmerz dieselbe Form, auch wenn die Tools unterschiedlich sind. Die Lücke zwischen der Toolchain auf dem Rechner eines Entwicklers und der auf dem Build-Server ist der Ursprung von unzuverlässigen Builds. Eine Toolchain, die sich von Anfang bis Ende selbst pinnt, ist die richtige Richtung – unabhängig von der Plattform.

Ein Vorbehalt zur Cloudflare-Rahmung: Die Geschichte „Machen Sie Ihre Agenten schneller" ist gutes Marketing und zum Teil wahr, aber es ist noch früh. Bundled Dev, der Modus, der mit Hilfe von Cloudflares eigenem Dashboard-Team entwickelt wurde, steckt noch hinter einem experimentellen Flag und ist nicht freigegeben. Behandeln Sie die Aussagen zur Agentengeschwindigkeit als Grund, dies genau zu beobachten, nicht als Grund, heute die Plattform zu wechseln.

Wenn es Ihnen bekannt vorkommt, Toolchains und CI über eine wachsende Anzahl von Repositories hinweg konsistent zu halten, sprechen wir miteinander.