Vite+ 1.0 unisce sette strumenti JS in un solo comando. Ecco quando conviene fare il cambio.

VoidZero ha rilasciato Vite+ 1.0 il 28 settembre, lo stesso giorno in cui Cloudflare celebrava il suo Birthday Week. L'idea è semplice: un unico comando, vp, e un unico vite.config.ts, al posto dell'ammasso di strumenti che un normale progetto JavaScript trascina con sé. Una singola dipendenza vite-plus sostituisce Vite, Vitest, un linter, un formatter, un runner per i Git hook, un task runner e un gestore delle versioni di Node. I comandi hanno lo stesso significato in ogni repository: vp dev, vp check, vp test, vp build, vp run. Il rilascio è sotto licenza MIT, si avvicina ai due milioni di download settimanali ed è già incluso in più di 2.600 repository pubblici.

Internamente include Vite 8, Vitest 5, Rolldown, Oxlint e Oxfmt, con cache dei task integrata. Il linter e il formatter sono scritti in Rust, quindi i controlli sono veloci. I dati forniti da VoidZero indicano che Oxlint è da 50 a 100 volte più veloce di ESLint e Oxfmt fino a 30 volte più veloce di Prettier. Vitest 5 è fino al 50% più veloce di Vitest 4, e il compilatore Oxc React gira circa 10 volte più veloce del plugin Babel che sostituisce. Cloudflare, che ora possiede VoidZero, ha inquadrato il lavoro sulla velocità attorno a un punto su cui vale la pena soffermarsi: gli agenti di coding restano in attesa mentre la toolchain lavora, quindi una volta che l'inferenza diventa rapida, il type-checking e il linting diventano il collo di bottiglia.

Ecco la nostra lettura onesta. Il vantaggio è reale, e non riguarda principalmente le battiture che si risparmiano.

Quello che elimina davvero è il disallineamento

Quando costruiamo app cloud-native per clienti enterprise, la perdita graduale non è mai uno strumento rotto. È il divario tra gli strumenti. La versione di ESLint sul laptop di uno sviluppatore che non è quella usata in CI. La configurazione di Prettier che formatta in modo diverso su due macchine. La versione di Node che nessuno ha fissato. Sono piccoli problemi, e i piccoli problemi ripetuti su una dozzina di repository e qualche centinaio di build diventano costosi. Vite+ testa il suo stack come un'unica unità e lo aggiorna come un'unica unità. È questo il punto che ripaga.

La stessa caratteristica è anche il limite, quindi bisogna entrarci con gli occhi aperti. Si aggiorna quando Vite+ si aggiorna. Si cede un insieme di configurazioni che si controllano per i default di un unico fornitore. Per un nuovo progetto, è un sì facile. Per una codebase consolidata con un set di regole ESLint attentamente calibrato, la domanda reale è se Oxlint copre le regole da cui si dipende, e il lancio non risponde a questa domanda per la propria configurazione specifica.

Cosa diremmo a un team questa settimana

• Stai iniziando qualcosa di nuovo? Esegui vp create e salta la settimana che altrimenti spenderesti a configurare lint, format, test e CI. I default sono ragionevoli.
• Hai un progetto esistente? Non smontare nulla a metà sprint. Esegui vp migrate su un branch. Stampa il suo piano prima di toccare un file, quindi analizza quel piano, esegui l'intera test suite e solo allora decidi.
• Fissa la versione di vite-plus e lascia che sia la CI, non i singoli laptop, la fonte di verità per la toolchain. Questa sola abitudine elimina la maggior parte dei ticket «funziona sulla mia macchina».

L'aspetto della sicurezza che tutti trascurano

Una dipendenza che ne sostituisce sette è una superficie d'attacco più piccola e un audit più breve. Durante i nostri incarichi di pentesting e le revisioni delle dipendenze, la lunga coda delle dipendenze di sviluppo transitive è un punto debole ricorrente: plugin non mantenuti, formatter abbandonati, un pacchetto per i Git hook che nessuno apre da tre anni. Consolidarsi su una toolchain revisionata e ben finanziata aiuta, a patto di trattare quella singola dipendenza come critica e mantenerla aggiornata. La concentrazione è a doppio taglio: un bug nell'unica cosa da cui ora tutti dipendono raggiunge tutti contemporaneamente.

Questo ragionamento vale anche oltre il web. Nel nostro lavoro su iOS e Android nativi il problema ha la stessa forma anche quando gli strumenti sono diversi. Il divario tra la toolchain sulla macchina di uno sviluppatore e quella sul server di build è l'origine delle build instabili. Una toolchain che si fissa dall'inizio alla fine è la direzione giusta qualunque sia la piattaforma.

Una nota di cautela sul framing di Cloudflare. La storia «rendi i tuoi agenti più veloci» è un buon marketing e in parte vera, ma è prematuro. Bundled Dev, la modalità costruita con l'aiuto del team del dashboard di Cloudflare, è ancora dietro un flag sperimentale e non rilasciata. Considera le affermazioni sulla velocità degli agenti come un motivo per seguire attentamente questo progetto, non come un motivo per cambiare piattaforma oggi.

Se mantenere toolchain e CI coerenti su un insieme crescente di repository ti suona familiare, parliamone.