Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Handhabung von NPM-Tags
npm-Registries unterstützen *Tags*, bei denen es sich um Zeichenkettenaliase für Paketversionen handelt. Sie können Tags verwenden, um einen Alias anstelle von Versionsnummern bereitzustellen. Sie könnten beispielsweise ein Projekt mit mehreren Entwicklungsströmen haben und für jeden Stream ein anderes Tag (z. B. `stable``beta`,`dev`,,`canary`) verwenden. Weitere Informationen finden Sie unter [dist-tag](https://docs.npmjs.com/cli/dist-tag) auf der npm-Website.
Standardmäßig verwendet npm das `latest` Tag, um die aktuelle Version eines Pakets zu identifizieren. `npm install pkg`(ohne `@version` oder `@tag` Spezifizierer) installiert das neueste Tag. In der Regel verwenden Projekte das neueste Tag nur für stabile Release-Versionen. Andere Tags werden für instabile Versionen oder Vorabversionen verwendet.
## Bearbeiten Sie Tags mit dem NPM-Client
Die drei `npm dist-tag` Befehle (`add``rm`, und`ls`) funktionieren in CodeArtifact Repositorys genauso wie in der [NPM-Standardregistrierung](https://registry.npmjs.com/).
## npm-Tags und die API CopyPackageVersions
Wenn Sie die `CopyPackageVersions` API verwenden, um eine npm-Paketversion zu kopieren, werden alle Tags, die dieser Version einen Alias geben, in das Ziel-Repository kopiert. Wenn eine kopierte Version über ein Tag verfügt, das auch im Ziel-Repository vorhanden ist, wird beim Kopiervorgang der Tag-Wert im Ziel-Repository so festgelegt, dass er dem Wert im Quell-Repository entspricht.
Nehmen wir zum Beispiel an, dass sowohl Repository S als auch Repository D eine einzige Version des `web-helper` Pakets mit dem neuesten Tag-Set enthalten, wie in dieser Tabelle dargestellt.
****
| Repository | Package name | Paket-Tags |
| --- | --- | --- |
| S | `web-helper` | *neueste* Version (Alias für Version 1.0.1) |
| D | `web-helper` | *latest* (Alias für Version 1.0.0) |
`CopyPackageVersions`wird aufgerufen, um `web-helper` 1.0.1 von S nach D zu kopieren. Nach Abschluss des Vorgangs hat das `latest` Tag on `web-helper` im Projektarchiv D den Alias 1.0.1, nicht 1.0.0.
Wenn Sie Tags nach dem Kopieren ändern müssen, verwenden Sie den `npm dist-tag` Befehl, um Tags direkt im Ziel-Repository zu ändern. Weitere Informationen zur `CopyPackageVersions` API finden Sie unter [Pakete zwischen Repositorys kopieren](copy-package.md).
## npm-Tags und Upstream-Repositorys
Wenn npm die Tags für ein Paket anfordert und Versionen dieses Pakets auch in einem Upstream-Repository vorhanden sind, werden die Tags CodeArtifact zusammengeführt, bevor sie an den Client zurückgegeben werden. Ein Repository mit dem Namen R hat beispielsweise ein Upstream-Repository mit dem Namen U. Die folgende Tabelle zeigt die Tags für ein Paket mit dem Namen`web-helper`, das in beiden Repositorys vorhanden ist.
****
| Repository | Package name | Paket-Tags |
| --- | --- | --- |
| R | `web-helper` | *aktuell* (Alias für Version 1.0.0) |
| U | `web-helper` | *alpha* (Alias für Version 1.0.1) |
In diesem Fall empfängt der npm-Client, wenn er die Tags für das `web-helper` Paket aus dem Repository R abruft, sowohl die *neuesten* als auch die *Alpha-Tags*. Die Versionen, auf die die Tags verweisen, werden sich nicht ändern.
Wenn dasselbe Tag für dasselbe Paket sowohl im Upstream- als auch im Downstream-Repository vorhanden ist, wird das Tag CodeArtifact verwendet, das im *Upstream-Repository* vorhanden ist. Nehmen wir zum Beispiel an, dass die Tags auf *Webhelper* so geändert wurden, dass sie wie folgt aussehen.
****
| Repository | Package name | Paket-Tags |
| --- | --- | --- |
| R | `web-helper` | *aktuell* (Alias für Version 1.0.0) |
| U | `web-helper` | *aktuell* (Alias für Version 1.0.1) |
In diesem Fall, wenn der npm-Client die Tags für das Paket *web-helper* aus dem Repository R abruft, verwendet das *neueste* Tag einen Alias für die Version *1.0.1*, da sich diese im Upstream-Repository befindet. Dies macht es einfach, neue Paketversionen in einem Upstream-Repository, die noch nicht in einem Downstream-Repository vorhanden sind, durch Ausführen zu konsumieren. `npm update`
Die Verwendung des Tags im Upstream-Repository kann problematisch sein, wenn neue Versionen eines Pakets in einem Downstream-Repository veröffentlicht werden. Nehmen wir zum Beispiel an, dass das neueste Tag im Paket *web-helper* sowohl in R als auch in U identisch ist.
****
| Repository | Package name | Paket-Tags |
| --- | --- | --- |
| R | `web-helper` | *neueste* Version (Alias für Version 1.0.1) |
| U | `web-helper` | *latest* (Alias für Version 1.0.1) |
Wenn Version 1.0.2 auf R veröffentlicht wird, aktualisiert npm das *neueste* Tag auf 1.0.2.
****
| Repository | Package name | Paket-Tags |
| --- | --- | --- |
| R | `web-helper` | *neueste* Version (Alias für Version 1.0.2) |
| U | `web-helper` | *latest* (Alias für Version 1.0.1) |
Der npm-Client sieht diesen Tag-Wert jedoch nie, da der Wert von *latest* in U 1.0.1 ist. Wenn es unmittelbar nach der Veröffentlichung von 1.0.2 `npm install` gegen das Repository R ausgeführt wird, wird 1.0.1 anstelle der Version installiert, die gerade veröffentlicht wurde. Um die zuletzt veröffentlichte Version zu installieren, müssen Sie die genaue Paketversion wie folgt angeben.
```
npm install web-helper@1.0.2
```