Använda npm-omfång för att hantera paket i Azure Artefakt

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

npm-omfång hjälper till att kategorisera relaterade paket i grupper. De låter dig skapa paket med samma namn som paket som skapats av andra användare utan konflikter. Med hjälp av omfång kan du separera offentliga och privata paket genom att lägga till omfångsprefixet @scopeName och konfigurera filen så att den .npmrc använder ett flöde med det omfånget.

Azure Artifacts stöder publicering och nedladdning av både begränsade och ej begränsade paket från feeds eller offentliga register. npm-omfång är särskilt användbara när du arbetar med lokalt installerade lokala servrar som inte har internetåtkomst, eftersom det inte är möjligt att konfigurera överordnade källor i dessa scenarier. Sammanfattningsvis när du använder omfång:

• Du behöver inte oroa dig för namnkollisioner.
• Du behöver inte ändra npm-registret för att installera eller publicera paket.
• Varje npm-organisation eller användare har ett eget omfång, och endast ägare eller omfångsmedlemmar kan publicera paket till det omfånget.

Prerequisites

Ansluta till din feed

Innan du konfigurerar npm-omfång ansluter du projektet till din Azure Artifacts feed. Kontrollera att du uppfyller förutsättningarna och skapar en feed och följ sedan de här stegen.

Azure Artifacts rekommenderar att du använder två separata .npmrc-filer. Behåll en fil i användarkatalogen för att lagra dina autentiseringsuppgifter och behåll den andra filen i samma katalog som din package.json-fil för att lagra din feedspecifika konfiguration.

vsts-npm-auth -config .npmrc

Omfångskonfiguration

Om du vill använda scope med Azure Artifacts uppdaterar du projektets .npmrc-fil så att de paket med scope som du publicerar eller installerar hämtas via ditt feed. Ersätt registry=<YOUR_SOURCE_URL> med @ScopeName:registry=<YOUR_SOURCE_URL>.

Uppdatera även package.json-filen så att den innehåller både omfångsnamnet och paketnamnet, till exempel: { "name": "@ScopeName/PackageName" }. I följande exempel visas hur du konfigurerar organisationsövergripande och projektövergripande flöden.

• Organisationsavgränsat flöde:

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

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

• Projektspecifikt flöde:

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

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

Example

• .npmrc-filen:

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

• Filen 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"
    }
  }
  

Publicera skopade paket

När du har konfigurerat omfånget och uppdaterat projektfilerna öppnar du ett kommandotolkfönster, navigerar till projektkatalogen och kör följande kommando för att publicera ditt begränsade paket. I föregående exempel publiceras paketet under omfånget @local .

npm publish

Uppströms källor jämfört med tillämpningsområde

Överordnade källor ger mest flexibilitet. Genom att använda överordnade källor kan du använda både begränsade och ej begränsade paket från din Azure Artifacts feed samtidigt som du använder paket från offentliga register, till exempel npmjs.com. Den här metoden fungerar bra när du vill att en enda feed ska fungera som huvudkälla för både interna paket och godkända externa beroenden.

Behörighetsområden är mer restriktiva, men de kan fortfarande vara ett praktiskt alternativ i rätt sammanhang. När du använder scope måste varje paketnamn börja med @<scope>, vilket innebär att du måste införa och hålla fast vid den namngivningskonventionen för dina paket. Om du till exempel publicerar ett paket som @local/my-packagemåste du fortsätta att använda det begränsade namnet var som helst där paketet refereras.

Det här kravet kan lägga till omkostnader, särskilt om du planerar att publicera samma paket i ett offentligt register senare. Om du tar bort omfång när du distribuerar paketen måste du även uppdatera motsvarande referenser i dinapackage.json-filer och eventuella beroende projekt.

Även med de här begränsningarna kan scope fungera som ett rimligt alternativ när källor högre upp i kedjan inte är praktiska. Detta gäller särskilt i isolerade eller lokalt installerade miljöer där åtkomst till offentliga register inte är tillgänglig och du vill undvika paketnamnskollisioner samtidigt som paketen hålls ordnade i feeden.

Relaterat innehåll

• Npm-granskning

• Publicera npm-paket med Azure-pipelines (YAML/klassisk)

• Använda paket från npm-registret