Verwenden von npm-Bereichen zum Verwalten von Paketen in Azure Artifact

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

Npm-Bereiche helfen beim Kategorisieren verwandter Pakete in Gruppen. Sie ermöglichen es Ihnen, Pakete mit denselben Namen wie Pakete zu erstellen, die von anderen Benutzern ohne Konflikte erstellt wurden. Mithilfe von Bereichen können Sie öffentliche und private Pakete trennen, indem Sie das Bereichspräfix @scopeName hinzufügen und die .npmrc Datei so konfigurieren, dass ein Feed mit diesem Bereich verwendet wird.

Azure Artifacts unterstützt das Veröffentlichen und Herunterladen von bereichsbezogenen und nicht bereichsbezogenen Paketen aus Feeds oder öffentlichen Registrierungen. npm-Bereiche sind besonders nützlich, wenn Sie mit selbst gehosteten lokalen Servern arbeiten, die keinen Internetzugang haben, da das Konfigurieren von Upstreamquellen in diesen Szenarien nicht möglich ist. Zusammengefasst: Wenn Sie Scopes verwenden:

• Sie müssen sich keine Gedanken über Namenskonflikte machen.
• Sie müssen die npm-Registrierung nicht ändern, um Pakete zu installieren oder zu veröffentlichen.
• Jede npm-Organisation oder jeder Benutzer verfügt über einen eigenen Bereich, und nur der Besitzer oder bereichsmitglieder können Pakete in diesem Bereich veröffentlichen.

Prerequisites

Herstellen einer Verbindung mit Ihrem Feed

Bevor Sie npm-Bereiche konfigurieren, verbinden Sie Ihr Projekt mit Ihrem Azure Artifacts Feed. Stellen Sie sicher, dass Sie die Voraussetzungen erfüllen und einen Feed erstellen, und führen Sie dann die folgenden Schritte aus.

Azure Artifacts empfiehlt die Verwendung von zwei separaten NPMRC-Dateien. Bewahren Sie eine Datei in Ihrem Benutzerverzeichnis auf, um Ihre Anmeldeinformationen zu speichern, und behalten Sie die zweite Datei im selben Verzeichnis wie Ihre package.json Datei, um Ihre feedspezifische Konfiguration zu speichern.

vsts-npm-auth -config .npmrc

Bereichseinrichtung

Um Scopes mit Azure Artifacts zu verwenden, aktualisieren Sie die .npmrc-Datei Ihres Projekts, damit die Pakete mit einem Scope, die Sie veröffentlichen oder installieren, über Ihren Feed aufgelöst werden. Ersetzen Sie registry=<YOUR_SOURCE_URL> mit @ScopeName:registry=<YOUR_SOURCE_URL>.

Aktualisieren Sie außerdem ihrepackage.json Datei so, dass sie sowohl den Bereichsnamen als auch den Paketnamen enthält, z. B.: { "name": "@ScopeName/PackageName" }. Die folgenden Beispiele zeigen, wie Sie organisationsweite und projektbezogene Feeds konfigurieren.

• Organisationsspezifischer Feed:

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

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

• Projektbezogener Feed:

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

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

Example

• Die NPMRC-Datei :

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

• Die package.json Datei:

  {
    "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"
    }
  }
  

Veröffentlichen von scoped Paketen

Nachdem Sie den Bereich konfiguriert und Die Projektdateien aktualisiert haben, öffnen Sie ein Eingabeaufforderungsfenster, navigieren Sie zu Ihrem Projektverzeichnis, und führen Sie den folgenden Befehl aus, um das bereichsbezogene Paket zu veröffentlichen. Im vorherigen Beispiel wird das Paket im Scope @local veröffentlicht.

npm publish

Upstreamquellen im Vergleich zu Gültigkeitsbereichen

Upstreamquellen bieten die größte Flexibilität. Mithilfe von Upstreamquellen können Sie sowohl bereichsbezogene als auch nicht bereichsbezogene Pakete aus Ihrem Azure Artifacts-Feed nutzen und gleichzeitig Pakete aus öffentlichen Registrierungen wie npmjs.com verwenden. Dieser Ansatz eignet sich gut, wenn ein einzelner Feed sowohl für interne Pakete als auch für genehmigte externe Abhängigkeiten als Hauptquelle fungieren soll.

Geltungsbereiche sind stärker eingeschränkt, können im passenden Anwendungsfall aber dennoch eine praktische Option sein. Wenn Sie Scopes verwenden, muss jeder Paketname mit @<scope> beginnen, das bedeutet, dass Sie diese Benennungskonvention für alle Ihre Pakete übernehmen und beibehalten müssen. Wenn Sie z. B. ein Paket als @local/my-package veröffentlichen, müssen Sie diesen Scoped-Namen überall dort weiter verwenden, wo auf das Paket verwiesen wird.

Diese Anforderung kann Mehraufwand hinzufügen, insbesondere, wenn Sie die gleichen Pakete später in einer öffentlichen Registrierung veröffentlichen möchten. Wenn Sie Bereiche entfernen, wenn Sie Ihre Pakete bereitstellen, müssen Sie auch die entsprechenden Verweise in Ihren package.json Dateien und abhängigen Projekten aktualisieren.

Auch mit diesen Einschränkungen können Geltungsbereiche eine praktikable Alternative sein, wenn vorgelagerte Quellen nicht infrage kommen. Dies gilt insbesondere in isolierten oder selbst gehosteten Umgebungen, in denen der Zugriff auf öffentliche Registrierungen nicht verfügbar ist und Sie Paketnamenkonflikte vermeiden möchten, während Pakete in Ihrem Feed organisiert bleiben.

Verwandte Inhalte

• Npm-Prüfung

• Veröffentlichen von npm-Paketen mit Azure Pipelines (YAML/Classic)

• Verwenden von Paketen aus der npm-Registrierung