Il vostro team vuole pubblicare la sua prima libreria JavaScript dalla sua pipeline automatizzata. Chi crea il pacchetto, chi ne esamina il contenuto e quando viene convalidata l'identità della pipeline? Entrambe le modifiche npm annunciate il 2 ottobre 2026 rendono questa sequenza più importante. Un pacchetto pronto per essere esaminato e una configurazione di fiducia valida sono due stati diversi.
Il primo pacchetto aggiunge un passaggio al lancio
Il nostro articolo del 1° ottobre sulle fasi e permessi di pubblicazione npm descrive la separazione dei diritti; questo articolo esamina i nuovi pacchetti e il ciclo di convalida della fiducia annunciato il 2 ottobre.
Prendiamo una libreria fittizia, riservata al nostro scenario. Il suo archivio contiene il codice destinato ad altre applicazioni. La pipeline prepara questo archivio, ma una persona deve poterlo esaminare prima che venga distribuita una versione utilizzabile. La questione non è solo «l’automazione può pubblicare?» : bisogna anche sapere cosa può preparare e chi decide della sua messa a disposizione.
Il 2 ottobre, npm ha annunciato la possibilità di creare un nuovo pacchetto con npm stage publish, da una sessione locale o un token granulare, incluso un token limitato alla preparazione. La versione sottoposta entra in una coda di revisione e deve essere promossa da un manutentore prima di diventare installabile. La configurazione del pacchetto e della pubblicazione affidabile può quindi essere organizzata. Annuncio sui nuovi pacchetti.
La pubblicazione staged indica questa pubblicazione in attesa di approvazione. La trusted publishing è un meccanismo separato: autorizza un ambiente automatizzato identificato ad agire sul pacchetto. Potete quindi avere un archivio in attesa e una fiducia non validata, o una fiducia valida con un archivio ancora non approvato. L’articolo esamina questi stati, piuttosto che riunire tutto il lancio sotto un pulsante « pubblica ».
Il cambiamento delle 48 ore riguarda la fiducia non convalidata
L'altro annuncio del 2 ottobre riguarda le configurazioni di trusted publishing non convalidate. Esse scadono 48 ore dopo la loro creazione. Una prima pubblicazione riuscita le convalida e le sottrae a questa scadenza. Un cambiamento di identità del repository o del progetto richiede una nuova relazione di fiducia; una modifica ordinaria non azzera il conteggio. Le configurazioni scadute rimangono visibili e devono essere ricreate per aprire una nuova finestra. Annuncio npm sulla scadenza.
Lo stesso annuncio precisa il rifiuto dei token provenienti da eventi GitHub Actions issue_comment, oltre alla restrizione già applicata a pull_request_target. Un trigger di workflow descrive la situazione in cui la pipeline si avvia. Qui, un contesto rifiutato non diventa autorizzato perché il suo archivio è stato approvato. Limitazione dei contesti di pubblicazione.
Non trasformate le 48 ore in durata di vita di tutti i vostri segreti né in termine universale di promozione di una versione. Questa finestra riguarda uno stato preciso della configurazione. Lo scenario esatto che valida la fiducia deve essere constatato nel vostro processo: la sola presenza di un archivio in attesa non è sufficiente a dimostrarlo.
Disegnare il percorso prima di avviare l'automazione
Scrivete una scheda con il nome del pacchetto, il suo responsabile, il deposito previsto e la versione iniziale. Aggiungete il componente che produce l’archivio, la persona che lo esamina e quella che può promuoverlo. Una stessa persona può ricoprire più ruoli, ma queste decisioni devono rimanere identificabili.
La documentazione npm consultata il 6 ottobre descrive una versione di attesa 0.0.0-stage creata quando un pacchetto non esiste ancora. Questo segnaposto è pubblico; la versione inviata e il suo contenuto rimangono in attesa fino all'approvazione. Il staging ha quindi un effetto visibile sul registro prima della distribuzione del vostro archivio reale. La documentazione indica anche npm CLI 11.15.0 o più recente e Node 22.14.0 o più recente. Documentazione pubblicazione a tappe.
Per la nostra libreria fittizia, la prima verifica consiste nel confrontare l'archivio con ciò che doveva essere consegnato. Esaminate i file inclusi, le dipendenze e gli script che potrebbero essere eseguiti durante l'installazione. Fate questo in un ambiente isolato adatto al vostro progetto. Il fatto che un archivio provenga da una pipeline conosciuta non stabilisce che il suo contenuto corrisponda alla richiesta.
Documentate poi il passaggio tra preparazione e promozione. La persona che approva deve sapere quale archivio è stato esaminato e a quale versione corrisponde. Una prova di revisione di un altro file, anche se con un nome simile, non è una prova per questo artefatto. Il vostro tracciamento può utilizzare un'impronta del file nelle tracce private, senza sovraccaricare il messaggio destinato agli utenti.
Seguire i due cicli di vita
La tabella sottostante è un metodo di monitoraggio proposto, basato sugli stati di fiducia annunciati. Non descrive un'interfaccia npm inventata.
| Stato della fiducia | Significato da verificare | Azione della squadra |
|---|---|---|
| Non convalidata | Prima pubblicazione riuscita ancora non constatata | Preparare la convalida nella finestra prevista |
| Validata | Prima pubblicazione riuscita osservata | Sorvegliare l'identità e le autorizzazioni |
| Scaduta | Finestra di convalida completata | Ricreare la relazione dopo l'esame del motivo |
| Identità cambiata | Deposito o progetto diverso | Esaminare e stabilire la nuova relazione |
Accanto, tenete un tracciamento indipendente dell'archivio: preparato, esaminato, approvato e poi distribuito. La scadenza di una fiducia non prova che una versione sia stata ritirata. L'approvazione di un archivio non prova che un’altra pipeline sia autorizzato. Separando questi stati, potete identificare il responsabile corretto quando un'operazione fallisce.
Per il meccanismo di identità, spiegate al team cosa significa OpenID Connect, spesso abbreviato OIDC: la pipeline presenta una prova legata al suo contesto di esecuzione, piuttosto che un semplice segreto permanente copiato ovunque. La decisione utile resta l’identità effettivamente ammessa. Un’etichetta OIDC in una configurazione non sostituisce l’esame del repository, del workflow e del trigger.
Aggiungete un avviso operativo adatto al lancio: chi nota una configurazione ancora non convalidata, dove viene registrata la data di creazione e chi decide una ricreazione? Non ricreate automaticamente le relazioni senza capire perché scadono. Una difficoltà di coordinamento tra preparazione, revisione e lancio potrebbe altrimenti rimanere invisibile.
Testare i rifiuti con un modello locale
Prima di qualsiasi azione su un registro, potete costruire una simulazione locale degli stati. Riceve una configurazione fittizia, una data di creazione e un risultato di pubblicazione fittizio. Calcola se la relazione non è convalidata, convalidata o scaduta secondo il vostro modello dell'annuncio. Gli orari sono input di test, non osservazioni su npm.
Preparate quattro casi: relazione non convalidata nella finestra, relazione non convalidata dopo la scadenza, relazione convalidata e identità modificata. Per ogni caso, indicate la transizione prevista e la decisione che un responsabile dovrà prendere. Questa simulazione testa la vostra comprensione e la vostra procedura; non qualifica da sola il comportamento del registro.
Aggiungete rifiuti legati all’archivio: contenuto assente, versione esaminata diversa dalla versione proposta, approvazione mancante. Aggiungete anche un contesto di esecuzione vietato. Il messaggio ottenuto deve indicare quale dimensione è coinvolta, senza mostrare una prova di identità o un segreto. La risposta appropriata a un archivio non revisionato non è quella di modificare la fiducia della pipeline.
Per un successivo tentativo autorizzato su un registro, verificate prima lo spazio dei nomi, i proprietari e gli effetti di creazione pubblica. I comandi citati in questo articolo servono a identificare i meccanismi; nessun pacchetto è stato creato e nessun comando di preparazione, pubblicazione o promozione è stato eseguito per produrre questo contenuto.
Prevedere una ripresa comprensibile
Se la finestra scade, iniziate con la cronologia: quando è stata creata la relazione, quale evento avrebbe dovuto convalidarla e quale osservazione manca? Verificate se la pipeline ha effettivamente raggiunto la fase di pubblicazione, se la sua identità corrisponde e se il contesto è autorizzato. La ricreazione avviene dopo questa verifica, con il responsabile del lancio.
Se l’archivio resta in attesa, cercate dal lato dell’esame e dell’approvazione. Non forzate una pubblicazione diretta solo per sbloccare un calendario. La procedura deve precisare chi può decidere di abbandonare una versione, correggere l’archivio o riprendere la sequenza. In questo modo preservate l’utilità della separazione dei ruoli.
Per il vostro primo pacchetto, tenete a mente cinque criteri: artefatto ispezionato, identità rivista, convalida effettivamente osservata, diritto di promozione assegnato e procedura di scadenza documentata. Questa griglia non misura alcun guadagno di sicurezza complessivo; fornisce decisioni concrete da verificare. Quando manca un criterio, terminate la preparazione corrispondente prima di estendere la pipeline alle versioni successive.
Il lancio diventa più facile da spiegare quando ciascuno sa distinguere « pacchetto creato », « contenuto approvato » e « fiducia validata ». Gli annunci del 2 ottobre modificano questi passaggi, ma la vostra regola di squadra mantiene la sequenza. Provate prima a percorrerla con dati fittizi e rifiuti previsti: saprete poi quali prove raccogliere in un test reale autorizzato.
Fonti e data di verifica
Fonti aperte il 6 ottobre 2026: scadenza della fiducia, creazione di un nuovo pacchetto in staging e documentazione npm. Entrambi gli annunci risalgono al 2 ottobre; la documentazione vivente fornisce contesto. Lo scenario e la simulazione sono proposti, senza pubblicazione reale né risultato rivendicato.