Usare gli ambiti npm per gestire i pacchetti in Azure Artifact

servizi Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022

Gli ambiti npm consentono di classificare i pacchetti correlati in gruppi. Consentono di creare pacchetti con gli stessi nomi dei pacchetti creati da altri utenti senza conflitti. Usando gli ambiti, è possibile separare i pacchetti pubblici e privati aggiungendo il prefisso dell'ambito @scopeName e configurando il .npmrc file per l'uso di un feed con tale ambito.

Azure Artifacts supporta la pubblicazione e il download di pacchetti con ambito e senza ambito dai feed o dai registri pubblici. Gli ambiti npm sono particolarmente utili quando si lavora con server locali self-hosted che non hanno accesso a Internet, perché la configurazione di origini upstream in tali scenari non è fattibile. In sintesi, quando si utilizzano ambiti:

• Non è necessario preoccuparsi delle collisioni tra nomi.
• Non è necessario modificare il Registro di sistema npm per installare o pubblicare pacchetti.
• Ogni organizzazione npm o utente ha un proprio ambito e solo il proprietario o i membri dell'ambito possono pubblicare pacchetti in tale ambito.

Prerequisiti

Connetti al tuo feed

Prima di configurare gli ambiti npm, connettere il progetto al feed di Azure Artifacts. Assicurarsi di completare i prerequisiti e creare un feed e quindi seguire questa procedura.

Azure Artifacts consiglia di usare due file npmrc separati. Mantenere un file nella directory utente per archiviare le credenziali e mantenere il secondo file nella stessa directory del file package.json per archiviare la configurazione specifica del feed.

vsts-npm-auth -config .npmrc

Configurazione dell'ambito

Per usare gli scope con Azure Artifacts, aggiorna il file .npmrc del progetto in modo che i pacchetti con scope che pubblichi o installi vengano risolti tramite il feed. Sostituisci registry=<YOUR_SOURCE_URL> con @ScopeName:registry=<YOUR_SOURCE_URL>.

Aggiornare anche il file package.json in modo da includere sia il nome dell'ambito che il nome del pacchetto, ad esempio : { "name": "@ScopeName/PackageName" }. Gli esempi seguenti illustrano come configurare feed con ambito a livello di organizzazione e di progetto.

• feed a livello di organizzazione:

  @ScopeName:registry=https://pkgs.dev.azure.com/<ORGANIZATION_NAME>/_packaging/<FEED_NAME>/npm/registry/
  
  always-auth=true
  

  {
    "name": "@ScopeName/PackageName"
  }
  

• Feed a livello di progetto:

  @ScopeName:registry=https://pkgs.dev.azure.com/<ORGANIZATION_NAME>/<PROJECT_NAME>/_packaging/<FEED_NAME>/npm/registry/
  
  always-auth=true
  

  {
    "name": "@ScopeName/PackageName"
  }
  

Example

• Il file .npmrc:

  @local:registry=https://pkgs.dev.azure.com/FabrikamOrg/NpmDemo/_packaging/FabrikamFeed/npm/registry/
  
  always-auth=true
  

• File package.json :

  {
    "name": "@demo/js-e2e-express-server",
    "version": "2.0.0",
    "description": "JavaScript server written with Express.js",
    "main": "index.js",
    "directories": {
      "doc": "docs",
      "test": "test"
    }
  }
  

Pubblicare pacchetti definiti

Dopo aver configurato l'ambito e aggiornato i file di progetto, aprire una finestra del prompt dei comandi, passare alla directory del progetto ed eseguire il comando seguente per pubblicare il pacchetto con ambito. Nell'esempio precedente il pacchetto viene pubblicato nell'ambito @local .

npm publish

Origini upstream e ambiti

Le origini upstream offrono la massima flessibilità. Usando le origini upstream, è possibile utilizzare pacchetti con ambito e senza ambito dal feed Azure Artifacts usando anche pacchetti di registri pubblici, ad esempio npmjs.com. Questo approccio funziona bene quando si vuole che un singolo feed funga da origine principale sia per i pacchetti interni che per le dipendenze esterne approvate.

Gli ambiti sono più restrittivi, ma possono comunque essere un'opzione pratica nello scenario corretto. Quando si usano ambiti, ogni nome del pacchetto deve iniziare con @<scope>, il che significa che è necessario adottare e mantenere tale convenzione di denominazione nei pacchetti. Ad esempio, se si pubblica un pacchetto come @local/my-package, è necessario continuare a usare tale nome con ambito in qualsiasi punto a cui viene fatto riferimento al pacchetto.

Questo requisito può comportare un sovraccarico, soprattutto se si prevede di pubblicare gli stessi pacchetti in un registro pubblico in un secondo momento. Se si rimuovono gli ambiti quando si distribuiscono i pacchetti, è necessario aggiornare anche i riferimenti corrispondenti nei file package.json e nei progetti dipendenti.

Anche con queste limitazioni, gli scope possono rappresentare una valida alternativa quando le sorgenti upstream non sono utilizzabili. Ciò vale soprattutto in ambienti isolati o self-hosted in cui l'accesso ai registri pubblici non è disponibile e si vuole evitare conflitti di nomi dei pacchetti mantenendo i pacchetti organizzati all'interno del feed.

Contenuti correlati

• npm audit

• Pubblicare pacchetti npm con Azure Pipelines (YAML/classico)

• Usare pacchetti dal Registro di sistema npm