nvm è di nuovo di tendenza, ma il suo design incentrato sulla shell affronta una nuova guardia più veloce

nvm ha raggiunto il terzo posto in una rilevazione di GitHub Trending del 12 agosto, quasi un mese dopo che i manutentori hanno rilasciato la versione 0.40.6. Questa tempistica è significativa. La posizione riflette un rinnovato interesse degli sviluppatori, ma non identifica un nuovo rilascio o annuncio del 12 agosto.

L'evento datato alla base è il rilascio di nvm 0.40.6 del 15 luglio. Ha ampliato il supporto alle architetture, rafforzato la gestione dei download, migliorato la compatibilità con Alpine Linux e chiarito diversi comportamenti imprevedibili dei comandi. Queste modifiche affrontano normali problemi di ingegneria, senza introdurre una categoria di prodotto diversa.

Questa distinzione dà forma alla vera storia. nvm resta profondamente familiare, con circa 94.500 stelle su GitHub al momento della pubblicazione. Tuttavia, alternative compilate come fnm e Volta promettono avvio più rapido, cambio automatico in base al progetto e supporto nativo più ampio per le piattaforme.

Il rinnovato interesse mette quindi alla prova una domanda più ampia. Una funzione shell per utente può restare il modello mentale predefinito per il controllo delle versioni di Node.js mentre lo sviluppo si sposta tra shell locali, container, ambienti remoti e agenti automatizzati?

La tendenza di agosto rimanda a un rilascio di luglio

L'evento verificato è nvm 0.40.6, rilasciato il 15 luglio, non un nuovo annuncio del progetto pubblicato il 12 agosto.

GitHub Trending misura il momentum attuale di un repository, non la data di un evento di cronaca sottostante. Una posizione in quell'elenco può seguire un rilascio, un tutorial ampiamente condiviso, un accumulo di stelle o discussioni altrove. GitHub non fornisce una spiegazione pubblica del perché un particolare repository occupi una determinata posizione giornaliera.

Questo limita ciò che la classifica può dimostrare. Conferma un interesse visibile nel periodo rilevato, ma non stabilisce un improvviso aumento delle installazioni. Non può inoltre mostrare se tale attenzione sia stata generata da utenti esistenti, sviluppatori alle prime armi, account automatizzati o copertura esterna.

Il record datato del progetto è molto più chiaro. La cronologia dei rilasci ufficiale identifica la versione 0.40.6 come l'ultima release e registra il 15 luglio come data di pubblicazione. La release firmata ha seguito la versione 0.40.5, arrivata il 4 giugno.

La versione 0.40.6 ha aggiunto il supporto all'installazione per loongarch64 e il supporto arm64-musl su Alpine Linux. LoongArch è un'architettura di processore, mentre musl è la libreria C utilizzata da Alpine. Il supporto di entrambi amplia gli ambienti in cui nvm può selezionare un artefatto Node.js appropriato.

La release ha inoltre migliorato il comportamento delle installazioni dalla cache. Il suo elenco delle versioni locali ora riconosce gli archivi sorgente e i vecchi artefatti io.js, mentre il parsing di .nvmrc gestisce i commenti in modo più coerente. Un file .nvmrc registra la versione di Node prevista da un progetto.

Diverse correzioni riguardano la risoluzione dei comandi. Il downloader ora verifica che curl o wget esistano come eseguibili. Usa inoltre meccanismi della shell che aggirano alias e funzioni definite dall'utente con questi nomi.

Può sembrare un dettaglio minore, finché una shell personalizzata non intercetta un download. Uno sviluppatore potrebbe avere un alias che aggiunge flag, modifica un proxy o sostituisce completamente il comando. Risolvendo l'eseguibile effettivo, nvm riduce la variabilità tra un percorso di codice previsto e il comportamento della shell locale dell'utente.

La release ha inoltre modificato nvm install affinché la migrazione dei pacchetti e gli aggiornamenti degli alias avvengano quando la versione Node richiesta è già presente. I messaggi di errore sono diventati più espliciti quando nvm run o nvm exec non dispongono né di un argomento di versione né di un file .nvmrc.

Si tratta di modifiche di manutenzione, ma affrontano esattamente il confine in cui opera nvm. Non si colloca al di fuori della shell e non reindirizza silenziosamente ogni invocazione di Node. Diventa parte della sessione shell, modifica il suo ambiente e si basa sulle convenzioni relative ai file di profilo, alla ricerca degli eseguibili, agli alias e ai percorsi.

La classifica di agosto va letta al meglio attraverso questa lente. Gli sviluppatori non hanno improvvisamente scoperto un nuovo tipo di gestore di runtime. Hanno riportato l'attenzione su uno strumento familiare i cui manutentori stanno ancora correggendo i complessi margini dello sviluppo basato sulla shell.

Questo lavoro continuo è importante perché il runtime circostante continua a evolversi. Ad agosto 2026 Node.js disponeva contemporaneamente di rami Current, di supporto attivo a lungo termine, di manutenzione e di fine vita. Ogni ramo aggiuntivo offre ai team un motivo in più per controllare deliberatamente le versioni.

Perché nvm si adatta ancora al modo di pensare degli sviluppatori

nvm resta rilevante perché trasforma la selezione della versione di Node in un'azione esplicita della shell che gli sviluppatori possono ispezionare, ripetere e documentare.

Il repository nvm descrive il progetto come un gestore di versioni per utente e per shell, destinato a shell compatibili con POSIX. Supporta ambienti che includono Linux, macOS e Windows Subsystem for Linux. L'implementazione viene caricata nella shell invece di essere installata come un tradizionale eseguibile autonomo.

Questa architettura crea un modello di interazione diretto. Uno sviluppatore richiede una versione, la attiva e può ispezionare subito cosa è cambiato. Comandi come nvm install, nvm use, nvm current e nvm which corrispondono ad azioni distinte.

L'approccio si adatta bene anche ai file di progetto. Un repository può contenere un valore .nvmrc come una release esatta, una versione principale o un alias LTS. Eseguire nvm use da quella directory attiva il runtime installato corrispondente.

Questo modello resta comprensibile durante il troubleshooting. Quando un comando usa la versione Node sbagliata, lo sviluppatore può ispezionare la shell attiva, il relativo path, l'alias corrente e il file di progetto. Lo strumento espone la transizione invece di nasconderla dietro un servizio in background permanente.

Il controllo esplicito aiuta anche nei test di compatibilità. Il manutentore di una libreria può passare tra i rami Node supportati, eseguire una suite di test e riprodurre l'ambiente di un utente. Uno sviluppatore che mantiene software più datato può conservare un runtime legacy senza sostituire l'installazione di sistema.

La cadenza dei rilasci di Node mantiene utile questa capacità. Il calendario delle release di Node ufficiale indicava Node 26 come Current il 12 agosto 2026. Node 24 e Node 22 restavano linee LTS supportate, mentre Node 25 aveva già raggiunto la fine del ciclo di vita.

Questi rami sovrapposti creano una pressione pratica. Un'applicazione può puntare a una release LTS, una dipendenza può ancora richiedere una linea più vecchia e una libreria può testare il ramo Current. Usare qualsiasi runtime sia installato globalmente non è una strategia affidabile.

nvm offre ai singoli sviluppatori un modo per gestire questa sovrapposizione senza privilegi amministrativi. Ogni utente può conservare i file del runtime nel proprio account ed evitare di usare sudo per pacchetti npm installati globalmente all'interno di una versione attivata.

Anche l'età del progetto diventa un vantaggio. Modelli di inizializzazione della shell, file .nvmrc, script di installazione, consigli per il troubleshooting e abitudini dei team si sono accumulati attorno ad esso. La documentazione esistente spesso presume che uno sviluppatore possa eseguire nvm use prima di seguire il passaggio successivo.

Questa familiarità accumulata riduce il costo di adozione. Un team non deve concordare un nuovo formato di manifest prima che uno sviluppatore possa iniziare. Può aggiungere un .nvmrc, documentare il comando e ottenere un runtime locale più coerente.

La stessa familiarità aiuta i sistemi di coding automatizzato. Un agente che entra in un repository sconosciuto può leggere il file di versione prima di eseguire i test. Il contesto di progetto leggibile dagli esseri umani, inclusi requisiti del runtime e decisioni di configurazione, trova posto anche in una base di conoscenza ingegneristica ricercabile.

Tuttavia, la familiarità non deve essere confusa con una riproducibilità completa. Un file di versione regola una dipendenza importante, ma non cattura ogni gestore di pacchetti, comando globale, libreria nativa, variabile d'ambiente o differenza di sistema operativo.

nvm risolve il problema della selezione di Node all'interno di una shell. Non pretende di riprodurre un'intera workstation o immagine di deployment. Questa promessa più circoscritta spiega sia la sua longevità sia la pressione che ora arriva dai gestori più recenti.

nvm affronta gestori che eliminano il cambio manuale

La competizione principale non è nvm contro un altro nome di comando. È il controllo esplicito della shell contro la selezione automatica e consapevole del progetto della toolchain.

Fast Node Manager, solitamente chiamato fnm, è scritto in Rust e distribuito come programma autonomo. Le sue funzionalità documentate includono il supporto per macOS, Windows e Linux, oltre alla compatibilità sia con i file .node-version sia con .nvmrc.

Questa compatibilità è strategicamente importante. Un repository può mantenere il proprio .nvmrc esistente mentre i singoli sviluppatori provano un gestore diverso. Il file di progetto non garantisce più che tutti utilizzino il progetto che ha reso popolare quel formato.

L'elenco delle funzionalità di fnm pone l'accento sulla velocità di avvio, sul design a file singolo e sul cambio automatico. Queste priorità rispondono alle lamentele comuni sul caricamento di una grande funzione shell a ogni apertura del terminale.

Volta segue un percorso diverso. Installa shim, ovvero piccoli intercettori di comandi che selezionano lo strumento configurato prima di avviarlo. Un progetto può fissare Node e un gestore di pacchetti in package.json, permettendo alla scelta della toolchain di viaggiare con un manifest di progetto già esistente.

Secondo la guida di Volta, cambia automaticamente toolchain mentre gli utenti si spostano tra progetti. Associa inoltre i comandi dei pacchetti installati globalmente a uno specifico motore Node, riducendo la necessità di reinstallarli dopo ogni aggiornamento del runtime.

Entrambi gli approcci cercano di rendere il gestore di versioni meno visibile. Lo sviluppatore entra in una directory e invoca node, mentre il gestore risolve la selezione del progetto. Questo elimina il passaggio separato nvm use dal percorso normale.

nvm può supportare il cambio automatico tramite ricette shell e plugin. La sua documentazione include approcci forniti dalla comunità per attivare i valori .nvmrc quando un utente cambia directory. Tuttavia, il progetto principale non rende questo comportamento universale.

Questa prudenza preserva l'esplicitezza. Gli hook automatici modificano il comportamento della shell e possono introdurre un ulteriore livello di debugging. Un cambio manuale offre all'utente un momento chiaro in cui il path cambia.

Eppure il controllo manuale crea anche errore umano. Uno sviluppatore può aprire un terminale, entrare in un progetto, dimenticare di effettuare il cambio ed eseguire un runtime incompatibile. Un editor, un task runner o un client Git grafico possono avviarsi al di fuori della shell interattiva inizializzata.

Il contrasto diventa più netto su Windows. Il progetto principale di nvm si rivolge ad ambienti compatibili con POSIX, con il supporto Windows che generalmente arriva tramite WSL. fnm e Volta pubblicizzano un funzionamento nativo multipiattaforma, che può semplificare un team con sistemi operativi misti.

Le prestazioni sono un'altra fonte di pressione, ma le affermazioni sui benchmark richiedono cautela. Il tempo di avvio della shell dipende dalla configurazione, dai plugin, dallo stato del disco, dal comportamento del terminale e dal modo in cui viene caricato un gestore. Un binario compilato rapido non rende automaticamente ogni flusso di sviluppo significativamente più veloce.

La differenza più duratura è architetturale. nvm modifica l'ambiente della shell corrente dopo essere stato caricato. I gestori compilati possono collocare un eseguibile o uno shim stabile nel path, quindi scegliere il runtime per ogni invocazione.

Quella differenza incide su molto più dell'avvio del terminale. Cambia il comportamento degli strumenti quando vengono avviati da editor, script, pianificatori di attività o agenti. Un gestore che intercetta l'esecuzione può applicare la configurazione del progetto senza richiedere a ogni chiamante di caricare lo stesso profilo della shell.

nvm mantiene comunque un importante vantaggio di compatibilità. .nvmrc è diventata una convenzione riconoscibile e gli strumenti concorrenti spesso scelgono di leggerla. Questo rende il formato del file più duraturo di qualsiasi singola implementazione.

La classifica delle tendenze contiene quindi un ribaltamento. L'attenzione conferma la continua importanza del progetto, ma l'ecosistema circostante tratta sempre più la compatibilità con nvm come una funzionalità di base, anziché come un motivo per usare nvm stesso.

Il design della shell è al contempo il vantaggio e il rischio

Il meccanismo che rende nvm trasparente lo espone anche ai confini della configurazione della shell, dell'installazione e della fiducia, che i gestori standalone possono restringere.

Poiché nvm è una funzione della shell caricata tramite source, which nvm non fornisce la verifica prevista. Il progetto indica agli utenti di eseguire invece command -v nvm. Questo dettaglio illustra quanto facilmente possano venire meno le normali supposizioni sugli eseguibili.

L'installazione modifica inoltre i file di profilo o dipende da essi. A seconda della shell, uno sviluppatore potrebbe aver bisogno di .bashrc, .bash_profile, .zshrc o .profile. Un terminale può caricare un file diverso rispetto a un editor, una shell di login o un processo non interattivo.

Le build dei container espongono un altro confine. Le sessioni Bash non interattive normalmente non leggono gli stessi file di profilo di un terminale interattivo. La documentazione di nvm raccomanda di usare BASH_ENV o di caricare esplicitamente lo script all'interno del comando pertinente.

Questo processo funziona, ma richiede una configurazione deliberata. Un layer del container che installa Node in un processo della shell non espone automaticamente il risultato esattamente come previsto da un processo successivo. L'inizializzazione della shell resta parte della correttezza della build.

La release di luglio affronta diverse versioni di questo problema. Evita gli alias intorno agli strumenti di download, controlla gli eseguibili con maggiore attenzione, chiarisce il comportamento in caso di versioni mancanti e migliora il rilevamento dell'architettura. Ogni correzione riduce l'ambiguità nell'interfaccia tra nvm e il suo ambiente host.

La precedente release di giugno trasmetteva un segnale più urgente. La versione 0.40.5 ha risolto CVE-2026-10796 e rimosso un percorso eval che poteva consentire l'iniezione di comandi tramite stringhe di versione dannose fornite da un mirror. Ha inoltre rafforzato la convalida degli artefatti e la gestione degli URL dei mirror.

Questo problema non significa che l'uso ordinario di nvm sia intrinsecamente insicuro. Mostra perché il percorso di download di un gestore di versioni merita un esame di sicurezza. Lo strumento ottiene runtime eseguibili e prende decisioni usando metadati di versione remoti, mirror, checksum, header e comandi locali della shell.

La versione 0.40.6 ha proseguito questo lavoro documentando il confine di fiducia relativo ai payload e ai metadati dei mirror. Ha inoltre rifiutato nomi di alias LTS non sicuri provenienti da un indice mirror e ampliato la sanitizzazione degli header di autorizzazione.

Questi cambiamenti sono rilevanti per le aziende che instradano i download attraverso mirror interni. Un mirror può migliorare la disponibilità o il controllo della rete, ma diventa anche parte della catena di fornitura del runtime. La sanitizzazione dei metadati non può sostituire il controllo su chi gestisce quell'infrastruttura.

Il rischio si estende alle istruzioni di installazione copiate dai siti web. Inviare uno script remoto a una shell tramite pipe è pratico, ma l'utente dovrebbe ispezionare la fonte, fissare una release e comprendere la destinazione. La documentazione di nvm offre percorsi di installazione manuale per i team che richiedono una revisione più rigorosa.

Un'altra incertezza riguarda la responsabilità operativa. nvm è un software open source maturo, mantenuto attraverso contributi della comunità. La sua ampia base di utenti fornisce test e segnalazioni di problemi, ma l'ampia compatibilità espande anche il numero di combinazioni di shell, sistemi operativi, architetture e runtime storici.

L'ultima release mostra direttamente questa espansione. L'aggiunta di loongarch64, la correzione del comportamento arm64-musl, la conservazione delle decisioni sui binari macOS meno recenti e il supporto degli artefatti memorizzati nella cache dei sorgenti ampliano tutti la matrice di compatibilità.

I gestori più recenti non sfuggono a questo onere. Devono interpretare gli indici remoti di Node, scaricare gli artefatti corretti, integrarsi con le shell e rispettare i file del progetto. Un'implementazione compilata può eliminare parte del parsing della shell, ma introduce binari, shim, programmi di installazione e packaging specifico per piattaforma.

La conclusione scettica è quindi più circoscritta di “nvm è obsoleto”. Il progetto resta attivamente mantenuto e compatibile con una storia insolitamente ampia di release di Node. Il compromesso è che gli utenti partecipano in modo visibile alla gestione dell'ambiente.

Questa visibilità aiuta gli sviluppatori esperti a comprendere i guasti. Può frustrare i team che vogliono che ogni transizione di progetto avvenga automaticamente. Che sia un vantaggio dipende da quale modalità di errore un team preferisce analizzare.

Il ciclo di release di Node mantiene sotto pressione i gestori di versioni

nvm è di tendenza perché la gestione delle versioni di Node è ancora un'infrastruttura incompiuta, non perché gli sviluppatori abbiano improvvisamente bisogno di un tutorial sull'installazione di Node.

Le linee supportate di Node evolvono secondo un calendario pubblicato. Anche senza migrazioni insolite, i team affrontano regolarmente un ramo Current, una o più linee LTS e dipendenze in ritardo rispetto al runtime più recente.

Nell'agosto 2026, Node 26 era la linea Current e Node 24 era l'ultima linea LTS. Node 22 restava supportato, mentre Node 25 aveva raggiunto la fine del ciclo di vita. Questa variazione è sufficiente a rendere inaffidabile un unico runtime di sistema per diversi progetti attivi.

La pressione aumenta quando i progetti includono addon nativi. Un pacchetto contenente codice compilato può dipendere da una specifica interfaccia binaria dell'applicazione, da una libreria del sistema operativo o da un artefatto precompilato. Cambiare Node può esporre problemi di compatibilità che i pacchetti JavaScript puri evitano.

I gestori di versioni aiutano gli sviluppatori a eseguire i test prima che una migrazione raggiunga la produzione. Un team può eseguire la propria suite sulla linea LTS corrente, mantenere disponibile la linea distribuita e valutare il ramo Current senza sostituire ripetutamente un'unica installazione globale.

Tuttavia, la selezione locale non risolve la policy di deployment. Container, job di integrazione continua, buildpack di piattaforma e immagini di produzione spesso fissano Node in modo indipendente. Un repository può quindi contenere un .nvmrc, un tag di base del container, una matrice CI e un intervallo di engine in package.json.

Questi valori possono divergere. Il file locale può selezionare Node 24 mentre la CI testa Node 22 e la produzione usa ancora un'immagine più vecchia. Il gestore attiva correttamente la versione richiesta, ma non può decidere quale file rappresenti la policy dell'organizzazione.

Qui i gestori automatici avanzano il loro argomento più forte. Se uno strumento legge un manifest di progetto versionato e intercetta ogni invocazione, meno azioni locali dipendono dalla memoria. La macchina applica la selezione dichiarata in modo coerente.

nvm fa una scommessa organizzativa diversa. Fornisce primitive chiare, poi lascia ai team la decisione su come integrarle. Un progetto può usare versioni esatte, alias principali, alias LTS, hook della shell o comandi espliciti nella documentazione di configurazione.

La distinzione è rilevante anche per gli agenti di programmazione IA. Un agente può ispezionare .nvmrc e usare l'ambiente richiesto prima di installare le dipendenze. Tuttavia, l'agente deve comunque riconoscere che il file esiste e inizializzare nvm nella propria shell di esecuzione.

Uno strumento basato su shim può applicare la configurazione senza quel passaggio aggiuntivo. D'altro canto, il cambio nascosto può rendere i log più difficili da interpretare, a meno che l'automazione non registri il runtime risolto. La riproducibilità dipende da prove visibili, non soltanto dal comportamento automatico.

La migliore pratica per i team è trattare la selezione del runtime come una configurazione condivisa. Lo sviluppo locale, la CI, i container e la produzione dovrebbero puntare alla stessa linea Node supportata. I controlli automatizzati possono rilevare le discrepanze prima di una release.

Questa pratica non richiede di abbandonare nvm. Richiede di riconoscerne il ruolo effettivo. nvm controlla il runtime disponibile nella shell dell'utente; non impone coerenza in ogni ambiente di esecuzione.

La posizione del progetto nelle tendenze suggerisce che molti sviluppatori attribuiscono ancora valore a questo ruolo. La sua ampia base installata, i comandi familiari e il file di progetto portabile restano difficili da sostituire tutti insieme.

La pressione deriva dalle aspettative, piuttosto che da un singolo concorrente. Gli sviluppatori si aspettano sempre più che gli strumenti si inizializzino rapidamente, cambino versione automaticamente, funzionino su diversi sistemi operativi e si comportino allo stesso modo in terminali, editor e automazione.

nvm può soddisfare alcune aspettative attraverso la manutenzione continua e l'integrazione con la comunità. Altre derivano dal suo design fondamentale incentrato sulla shell. Affrontarle pienamente cambierebbe le qualità che rendono il progetto riconoscibile.

Cosa osservare dopo nvm 0.40.6

La fase successiva sarà decisa dal seguito dato alla sicurezza, dall'adozione dei flussi di lavoro automatici e dalla compatibilità con nuovi target Node e hardware.

Il primo segnale è un'altra release incentrata sulla sicurezza. Le versioni 0.40.5 e 0.40.6 hanno rafforzato i metadati remoti, la convalida degli artefatti, la gestione delle autorizzazioni e la fiducia nei mirror. Ulteriori cambiamenti in queste aree mostrerebbero che i confini della catena di fornitura restano una priorità di manutenzione attiva.

Ciò rafforzerebbe le ragioni a favore di strumenti consolidati quando i maintainer rispondono rapidamente e documentano chiaramente il rischio. Un lungo intervallo attorno a una debolezza divulgata nel percorso di download indebolirebbe la fiducia, soprattutto per le organizzazioni che usano mirror privati.

Il secondo segnale è la frequenza con cui i team mantengono .nvmrc ma lo eseguono tramite un altro gestore. Sia fnm sia altri strumenti possono trattare il file come input. Questo preserva la convenzione di nvm, trasferendo al contempo l'effettiva selezione del runtime a binari compilati o shim.

Una crescita visibile di questo schema indebolirebbe la posizione di nvm come implementazione predefinita. Al contempo, rafforzerebbe la sua eredità come progetto che ha stabilito una convenzione di configurazione duratura.

Il terzo segnale è il lavoro di compatibilità relativo a nuove architetture, varianti Linux e release di Node. La versione 0.40.6 ha aggiunto il supporto per loongarch64 e arm64-musl, migliorando al contempo l'installazione dei runtime macOS meno recenti.

Ulteriori cambiamenti di questo tipo rafforzerebbero l'argomento dell'ampia compatibilità di nvm. Lacune persistenti sulle piattaforme più recenti offrirebbero ai gestori multipiattaforma un'apertura più chiara, in particolare tra i team misti Windows, macOS e Linux.

La classifica GitHub non dovrebbe di per sé fungere da metrica decisiva. Le stelle e la posizione giornaliera misurano l'attenzione, mentre i team hanno bisogno di affidabilità, comportamento di sicurezza documentato e risoluzione coerente del runtime.

Gli sviluppatori che valutano il rinnovato interesse dovrebbero esaminare le proprie modalità di errore. Le persone dimenticano di cambiare versione oppure gli hook automatici generano comportamenti confusi? Gli editor e gli agenti ereditano l'ambiente corretto? CI e produzione concordano con la configurazione locale?

nvm resta una scelta credibile quando il controllo esplicito della shell, la compatibilità storica e il supporto di .nvmrc sono gli aspetti più importanti. Un gestore compilato merita valutazione quando velocità di avvio, cambio automatico o supporto nativo per Windows creano attriti misurabili.

Il passo successivo produttivo non è sostituire uno strumento funzionante perché è apparso in una lista di tendenze. Esaminate le dichiarazioni del runtime tra configurazione locale, CI, container e produzione. Poi verificate se nvm 0.40.6 rende questi percorsi prevedibili.

Se lo stesso progetto seleziona versioni Node diverse in questi ambienti, correggete prima tale incoerenza. Se le dichiarazioni concordano ma l'attivazione resta inaffidabile, confrontate un gestore basato su shim con il flusso di lavoro reale. Il risultato importante è una policy Node visibile e ripetibile, qualunque sia il gestore che la applica.