Utiliser des étendues npm pour gérer les packages dans Azure Artifact

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

Les étendues npm permettent de catégoriser les packages associés en groupes. Ils vous permettent de créer des packages avec les mêmes noms que les packages créés par d’autres utilisateurs sans conflit. En utilisant des étendues, vous pouvez séparer les packages publics et privés en ajoutant le préfixe d’étendue @scopeName et en configurant le .npmrc fichier pour utiliser un flux avec cette étendue.

Azure Artifacts prend en charge la publication et le téléchargement de packages avec portée et sans portée à partir de flux ou de registres publics. Les étendues npm sont particulièrement utiles lorsque vous travaillez avec des serveurs locaux auto-hébergés qui n’ont pas d’accès à Internet, car la configuration des sources en amont dans ces scénarios n’est pas réalisable. En résumé, lorsque vous utilisez des portées :

• Vous n’avez pas à vous soucier des collisions de noms.
• Vous n’avez pas besoin de modifier le registre npm pour installer ou publier des packages.
• Chaque organisation ou utilisateur npm a son propre scope, et seul le propriétaire ou les membres du scope peuvent publier des paquets dans ce scope.

Prerequisites

Se connecter à votre flux

Avant de configurer les étendues npm, connectez votre projet à votre flux de Azure Artifacts. Vérifiez que vous remplissez les prérequis et créez un flux, puis suivez ces étapes.

Azure Artifacts recommande d’utiliser deux fichiers .npmrc distincts. Conservez un fichier dans votre répertoire utilisateur pour stocker vos informations d’identification et conservez le deuxième fichier dans le même répertoire que votre fichier package.json pour stocker votre configuration spécifique au flux.

vsts-npm-auth -config .npmrc

Configuration de la portée

Pour utiliser des portées avec Azure Artifacts, mettez à jour le fichier .npmrc de votre projet afin que les packages à portée que vous publiez ou installez soient résolus via votre flux. Remplacez registry=<YOUR_SOURCE_URL> par @ScopeName:registry=<YOUR_SOURCE_URL>.

Mettez également à jour votre fichier package.json pour inclure à la fois le nom de l’étendue et le nom du package, par exemple : { "name": "@ScopeName/PackageName" }. Les exemples suivants montrent comment configurer des flux à l’échelle de l’organisation et du projet.

• Flux à l'échelle de l'organisation :

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

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

• Flux à l'échelle du projet :

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

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

Example

• Fichier .npmrc :

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

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

Publier des packages délimités

Après avoir configuré votre étendue et mis à jour vos fichiers projet, ouvrez une fenêtre d’invite de commandes, accédez à votre répertoire de projet et exécutez la commande suivante pour publier votre package étendu. Dans l’exemple précédent, le package est publié sous l’étendue @local .

npm publish

Sources en amont ou étendues

Les sources en amont offrent la plus grande flexibilité. En utilisant des sources en amont, vous pouvez utiliser des packages délimités et non étendus à partir de votre flux de Azure Artifacts tout en utilisant des packages à partir de registres publics tels que npmjs.com. Cette approche fonctionne bien lorsque vous souhaitez qu’un flux unique agisse comme source principale pour les packages internes et les dépendances externes approuvées.

Les portées sont plus restrictives, mais elles peuvent néanmoins constituer une option pratique dans le bon contexte. Lorsque vous utilisez des scopes, chaque nom de package doit commencer par @<scope>, ce qui signifie que vous devez adopter et respecter cette convention de nommage pour l’ensemble de vos packages. Par exemple, si vous publiez un package en tant que @local/my-package, vous devez continuer à utiliser ce nom délimité n’importe où le package est référencé.

Cette exigence peut ajouter une surcharge, en particulier si vous envisagez de publier les mêmes packages dans un registre public ultérieurement. Si vous supprimez des étendues lorsque vous déployez vos packages, vous devez également mettre à jour les références correspondantes dans vos fichiers package.json et tous les projets dépendants.

Même avec ces limitations, les étendues peuvent servir d’alternative viable lorsque les sources en amont ne sont pas pratiques. Cela est particulièrement vrai dans les environnements isolés ou auto-hébergés où l’accès aux registres publics n’est pas disponible et que vous souhaitez éviter les collisions de noms de package tout en conservant les packages organisés dans votre flux.

Contenu connexe

• Npm audit

• Publier des packages npm avec Azure Pipelines (YAML/Classic)

• Utiliser des packages à partir du registre npm