V+ (Vit Plus): l’ambiente “tutto incluso” che mette ordine in linting, formatting, test e workflow

Negli ultimi anni abbiamo normalizzato una certa “frammentazione” nel setup dei progetti frontend: scegli un bundler, poi un runner per i test, poi un formatter, poi un linter, poi il package manager “giusto”, poi i git hooks, poi la CI… Il risultato è spesso un mosaico di tool ottimi singolarmente, ma incollati insieme con configurazioni ridondanti e punti di rottura continui.

V+ (Vit Plus) nasce esattamente per eliminare quella colla. L’idea è semplice e ambiziosa: prendere le esigenze ricorrenti di quasi ogni app web e offrirle come un’esperienza unificata, con una configurazione centralizzata e comandi coerenti.

Il problema reale: non sono 2-3 strumenti, è un ecosistema

Quando si pensa allo “stack minimo” di un’applicazione web, vengono subito in mente quattro pilastri:

1. Linting (tipicamente ESLint)
2. Formatting (tipicamente Prettier)
3. Testing (Jest, Vitest, ecc.)
4. Bundling/dev server (spesso Vite)

In pratica però ogni progetto porta con sé altro:

• Package manager (npm/pnpm/bun…)
• Continuous Integration (config e pipeline)
• Git hooks (pre-commit, pre-push)
• Build di librerie (non solo app, ma package riusabili o tool interni)

Il punto non è che manchino strumenti: è l’opposto. Esistono troppe combinazioni possibili per ogni voce, e spesso il team finisce con:

• configurazioni duplicate
• standard difficili da imporre
• comportamenti diversi tra macchina locale e CI
• tempi di esecuzione non ottimali

Cos’è V+: un punto di ingresso unico

V+ prova a fare una cosa precisa: raggruppare ciò che serve a un progetto moderno in un unico CLI e un’unica configurazione, con integrazione “di default” tra i vari pezzi.

Questo significa:

• creazione progetto (app, monorepo, libreria)
• lint + format integrati
• test integrati
• comandi dev/build/preview integrati
• workflow di controllo qualità (check, stage, hook) già pronti

Installazione e filosofia d’uso

V+ si comporta come un tool “di sistema”: l’approccio tipico è installarlo globalmente e usarlo ovunque, un po’ come faresti con Node o un package manager.

Una volta installato, il CLI espone una serie di comandi sotto vp.

Creare un progetto: app, monorepo o libreria

Il comando chiave è vp create, che guida nella creazione di:

• standard application (setup classico)
• monorepo (struttura app + packages)
• library (codice da distribuire/riusare)

Durante lo scaffold puoi scegliere, ad esempio:

• package manager (es. pnpm)
• inizializzazione git
• setup di hook pre-commit
• file/standard per agenti AI (utile se il team usa strumenti assistiti)

Il risultato più interessante non è tanto la cartella generata, quanto l’assetto: pochi file di config, e un fulcro unico.

Una sola configurazione: v.config

La caratteristica che cambia davvero il modo di lavorare è che la configurazione tende a concentrarsi in un solo file (ad esempio v.config).

Qui vengono gestiti:

• regole di formatting
• regole di linting
• opzioni di type checking
• task di check/qualità
• comportamento dei file “staged” (pre-commit)

Lint e format integrati (stack OXC)

V+ usa Oxlint e Oxformat, strumenti basati su Rust con l’obiettivo di essere vicini a ESLint/Prettier come capacità, ma molto più rapidi e più semplici da far convivere, perché nativamente inseriti nello stesso sistema.

In pratica:

• vp lint esegue il linter
• vp format formatta il codice
• vp check fa entrambe le cose in sequenza

Type checking dentro il workflow di lint

Un dettaglio importante: la pipeline può includere type-aware linting e type checking. In molti progetti oggi si finisce a eseguire:

• ESLint
• Prettier
• tsc --noEmit

con tre comandi e tre logiche diverse.

Con V+ l’idea è rendere naturale che i controlli di tipo facciano parte del “check” complessivo, riducendo la possibilità di far passare codice che “sembra” OK ma non lo è.

Git hooks e pre-commit: standard forzati (nel modo giusto)

Uno dei vantaggi più pratici: il controllo qualità può diventare un blocco reale prima del commit.

Il meccanismo tipico è:

• sui file staged viene eseguito vp check (spesso con fix automatico)
• se qualcosa è fixabile, viene corretto
• se restano errori non risolvibili automaticamente, il commit viene interrotto

Questo è utile sempre, ma diventa fondamentale quando:

• il team è grande
• le PR arrivano da contesti diversi
• si usa molto codice generato (incluse soluzioni assistite): senza guardrail rigidi, la qualità degrada in fretta

Integrazione editor: formatting e linting mentre scrivi

Per lavorare bene serve che l’editor “senta” le stesse regole del progetto.

In VS Code, un extension pack dedicato abilita lint/format automatici coerenti con v.config: salvi un file e viene formattato secondo gli standard del repository, senza dipendere da configurazioni locali strane o estensioni sovrapposte.

Template e bootstrap di framework: partire da Vite (e oltre)

V+ non obbliga a un singolo tipo di progetto. Puoi:

• creare un progetto “base”
• oppure usare template/shortcut per partire con scaffolding noti

Ad esempio, puoi innestarti su una creazione stile Vite e scegliere framework (React, ecc.) e varianti (TypeScript). Il valore aggiunto è che il progetto nasce già allineato ai controlli di V+ (lint/format/hook/check), invece di doverli aggiungere e farli combaciare dopo.

Monorepo: struttura e comandi più lineari

Con l’opzione monorepo, trovi tipicamente:

• apps/ per le applicazioni
• packages/ per i moduli condivisi

I comandi diventano più ergonomici perché V+ può offrire scorciatoie per eseguire task su porzioni del repo (es. una singola app), e ogni area può avere configurazioni specifiche quando serve, senza perdere il controllo centrale.

Generator: scaffolding interno per pacchetti/progetti

Un’idea molto interessante è il supporto ai generator, cioè la possibilità di creare rapidamente nuovi package/app all’interno del monorepo seguendo template definiti.

Se il team ha un modo standard di iniziare un progetto (struttura cartelle, dipendenze, script, convenzioni), un generator riduce la variabilità e accelera il provisioning.

Testing: vp test con Vest

Per i test, l’esperienza è volutamente minimale:

• vp test per eseguire la suite
• vp test watch per la modalità watch
• vp test --coverage per la copertura

Sotto il cofano viene usato Vest, con un’impostazione molto familiare a chi arriva da Jest: aspettati un modello simile, ma integrato nello stesso “mondo” dei comandi V+.

Dev/build/preview: tutto quello che ti aspetti da Vite, ma unificato

Dato che V+ si appoggia a Vite per la parte app, i comandi tipici restano immediati:

• vp dev avvia il server di sviluppo
• vp build genera la build di produzione
• vp preview serve la build in locale per verificarla

Il beneficio qui non è reinvenzione: è coerenza. Usi lo stesso entrypoint CLI per tutto il ciclo di vita.

Packaging: librerie ed eseguibili

Oltre alle app, V+ include comandi per packaging di librerie o eseguibili (ad esempio vp pack), evitando di introdurre tool ad hoc anche per questa parte quando il progetto non è “solo una web app”.

Perché ha senso: meno decisioni ripetute, più standard eseguibili

La promessa di V+ non è “un tool magico”. È più concreta:

• riduce il numero di scelte che rifai ad ogni progetto
• accorcia il tempo di setup (meno file, meno incastri)
• rende gli standard parte del workflow (soprattutto con pre-commit e check)
• aumenta la velocità (stack Rust per lint/format)

Implicazione pratica

Se oggi il tuo repo ha:

• ESLint + Prettier + script custom
• tsc a parte
• husky/lint-staged o equivalenti
• CI che replica a fatica ciò che fai in locale

…un approccio unificato come V+ diventa interessante perché sposta il focus da “manutenere tooling” a “scrivere software”, con regole chiare e verificabili automaticamente.

Sintesi

V+ mette insieme ciò che normalmente è sparso: scaffold, lint/format, type checking, test, workflow pre-commit, comandi di build e supporto a monorepo. Il valore non è avere più funzionalità, ma averle integrate, veloci e configurate in un solo posto.

Se l’obiettivo del tuo team è ridurre attrito, configurazioni duplicate e divergenze tra ambienti, questo tipo di tool “batteria inclusa” non è una comodità: è un investimento diretto sulla qualità e sulla sostenibilità del progetto.