Trois avantages des scripts npm que vous ne connaissiez pas

March 03, 2020
Rédigé par

Trois avantages des scripts npm que vous ne connaissiez pas

L'écosystème Node.js regorge d'outils d'interface de ligne de commande (CLI) utiles. La plupart d'entre eux offrent des configurations ajustables pour faire exactement ce que vous voulez. Cependant, il peut arriver que vous ayez besoin de configurations et de scripts encore plus personnalisés. C'est là qu'interviennent les « scripts npm ». Vous les avez peut-être déjà utilisés pour configurer des scripts « build », « dev » ou « start », mais ils offrent encore d'autres possibilités. Dans ce blog post, nous allons aborder les fonctionnalités les plus utiles et certaines fonctionnalités cachées.

Avant de commencer, assurez-vous que la dernière version de npm est installée. Bien que nombre de ces fonctionnalités puissent être obtenues en utilisant yarnberry et pnpm, dans cet article, nous allons nous concentrer sur npm. Tous les éléments décrits ici ont été testés avec la version 6.10 de npm.

Que sont les scripts npm ?

Lorsque nous parlons de « scripts npm », nous parlons d'entrées dans le champ scripts du fichier package.json. Le champ scripts contient un objet dans lequel vous pouvez spécifier diverses commandes et scripts à exposer. Ces derniers peuvent être exécutés à l'aide de la commande npm run <script-name>.

Par exemple, si notre fichier package.json ressemble à ceci :

{
  "name": "demo",
  "scripts": {
    "example": "echo 'hello world'"
  }
}

Vous pourrez exécuter :

npm run example

Ceci est particulièrement pratique pour transmettre différents arguments à une commande CLI sans les ressaisir à chaque fois. De plus, vous pouvez accéder à tous les scripts exposés par vos dépendances, ce qui signifie que vous n'avez plus besoin de dépendances globales.

Par exemple, si vous voulez utiliser TypeScript, au lieu de demander à tout le monde de l'installer globalement à l'aide de la commande npm install -g typescript, vous pouvez l'installer en tant que dépendance de développement avec npm install --save-dev typescript, puis ajouter un script build à la section "scripts" :

  "scripts": {
    "build": "tsc"
  }

Cela fait, quiconque souhaite utiliser votre projet n'a pas besoin d'installer TypeScript globalement, mais peut exécuter npm run build après avoir exécuté npm install. Cela signifie également que les utilisateurs peuvent avoir plusieurs projets avec différentes versions installées de la même commande.

Cette création d'alias de commande est peut-être la raison pour laquelle les scripts npm sont le plus connus. Toutefois, vous disposez d'autres possibilités pour améliorer vos scripts npm !

Pre-/post-scripts

Parmi les conseils et astuces que nous allons évoquer dans cet article, celui-là est peut-être le plus connu, mais je pense qu'il mérite d'être abordé en raison de sa puissance.

Supposons que vous ayez la section « scripts » suivante :

  "scripts": {
    "prebuild": "rimraf dist",
    "build": "tsc",
    "postbuild": "npm run test",
    "test": "jest"
  }

Si vous exécutez npm run build, les actions ci-dessous seront automatiquement déclenchées :

  1. prebuild sera appelé en exécutant rimraf (outil) pour supprimer le dossier dist
  2. build est exécuté avec le compilateur TypeScript
  3. postbuild sera appelé en exécutant npm run test
  4. test est exécuté avec le canal de test jest

Cela fonctionne, car npm détecte automatiquement si un script a d'autres scripts nommés de la même manière, mais dotés du préfixe pre ou post et les exécute dans l'ordre respectif. C'est un excellent moyen d'enchaîner les commandes sans alourdir vos scripts. Voici quelques exemples d'utilisation :

  • suppression d'artefacts de build
  • exécution d'un linter avant les tests
  • téléchargement des données avant la construction d'une application

Le même comportement s'applique aux commandes intégrées. Par exemple, preinstallprepack. L'étrangeté ici est version, car cet élément fournit preversionversion et postversion. La différence entre version et postversion est que postversion sera appelé après que npm a validé les modifications effectuées dans preversion et version. Pour en savoir plus sur ces scripts de cycle de vie, consultez la documentation npm.

Variables d'environnement

Ce que nous allons voir maintenant s'est avéré une agréable surprise pour moi la première fois que je l'ai découvert. Lorsque vous exécutez une commande ou un script via npm run…, vos variables d'environnement sont automatiquement augmentées avec un ensemble de variables provenant de npm.

Toutes les variables d'environnement ont le préfixe npm_ et peuvent être regroupées en deux types :

  • Tout ce qui commence par npm_config_ est une configuration npm générale venant de votre configuration npm globale ou d'un fichier .npmrc propre au projet.
  • Tout ce qui commence par npm_package_ est propre à votre projet.

Si vous souhaitez connaître toutes les valeurs transmises aux scripts dans le projet, ajoutez l'entrée suivante à vos scripts :

{
  "scripts": {
    "check-env": "node -e 'console.log(process.env)' | grep npm"
  }
}

Ensuite, exécutez npm run check-env dans votre ligne de commande pour voir la liste de toutes les variables d'environnement que npm a définies pour vous. Voici ce qui a retenu mon attention :

  • Vous pouvez trouver chaque entrée de votre fichier package.json en tant que variable d'environnement. L'accès est similaire à l'accès à une propriété dans JSON, sauf qu'il utilise _ comme séparateur. Par exemple, npm_package_dependencies_twilio vous donne la version de twilio installée, ou npm_package_author_email vous donne le champ d'e-mail de la propriété author. Pour accéder aux valeurs d'un tableau, utilisez la valeur d'index précédée du préfixe _, comme npm_package_keywords_0 pour récupérer le premier mot-clé.
  • Vous pouvez obtenir la version de npm, la version de node et le système d'exploitation via npm_config_user_agentLe format est de type npm/6.10.0 node/v10.19.0 darwin x64, où darwin signifie macOS et x64 est l'architecture du processeur.
  • Vous pouvez obtenir le hachage git de HEAD via npm_package_gitHead.

Il y a de nombreuses variables utiles ici et je vous encourage à les découvrir, surtout si vous travaillez sur la création de scripts d'automatisation.

Consultez mon article si vous voulez en savoir plus sur les variables d'environnement dans Node.js en général.

Transmission et analyse des arguments

Jusqu'à présent, nous avons expliqué comment créer des scripts, quelles variables d'environnement sont définies et comment appeler les scripts. Cependant, vous voulez parfois être en mesure de transmettre des arguments à vos scripts afin qu'ils soient plus dynamiques. Il existe deux façons différentes de transmettre des arguments aux scripts npm.

La première méthode transmet simplement les arguments directement à votre commande réelle. Par exemple :

npm run build -- --watch

Sera exécuté comme suit :

tsc --watch

Ce qui est important ici, c'est -- suivi d'un espace. Tous les éléments qui apparaissent après sont transmis un à un dans la commande réelle du script. C'est utile dans des situations comme l'exemple illustré ci-dessus où vous exposez une commande de base comme tsc et lorsque vous souhaitez transmettre occasionnellement des arguments supplémentaires à la commande.

La deuxième option consiste à utiliser l'analyseur d'argument intégré de npm. C'est probablement l'une des fonctionnalités les moins connues des scripts npm mais j'étais super enthousiaste quand je l'ai découverte. Essentiellement, npm analyse tous les arguments que vous transmettez au script sauf s'ils sont transmis après le code -- suivi d'un espace. Une fois que npm les a analysés, ils sont disponibles sous npm_config_ dans les variables d'environnement.

Pour tester ceci, créez une nouvelle entrée scripts :

{
  "scripts": {
    "demo": "echo \"Hello $npm_config_first $npm_config_last\""
  }
}

Exécutez :

npm run demo --last=Kundel --first=Dominik

La sortie devrait être Hello Dominik Kundel. Il est important de noter que puisque nous ne configurons pas cet analyseur d'arguments, il n'est pas très flexible en ce qui concerne la syntaxe d'argument. Par exemple, si nous supprimons les signes = et réexécutons la même commande :

npm run demo --last Kundel --first Dominik

Nous obtenons Hello true true Kundel Dominik, parce qu'il considèrera --last et --first comme des indicateurs booléens, définira leur valeur sur true et transmettra le reste des arguments au script en tant qu'arguments non analysés, ce qui entraîne l'appel de echo "Hello $npm_config_first $npm_config_last" "Kundel" "Dominik".

Cependant, même si l'analyseur d'argument est relativement strict, c'est un outil très puissant si vous prévoyez de créer quelques scripts simples sans traiter l'analyse des arguments.

Outils utiles

Maintenant que nous avons abordé quelques façons d'utiliser les scripts npm et d'exploiter leur potentiel, je voudrais partager quelques-uns de mes outils préférés susceptibles de vous aider à améliorer vos scripts npm.

Ce ne sont que quelques outils et je suis certain qu'il y en a beaucoup d'autres. Si vous pensez que certains d'entre eux devraient être répertoriés ici, n'hésitez pas à m'envoyer un e-mail à l'adresse dkundel@twilio.com ou à m'envoyer un DM sur Twitter, je serai heureux de les ajouter ici.

Conclusion

Les scripts npm sont utiles pour améliorer l'expérience de développement pour vous et pour tous ceux qui travaillent sur votre projet. Ils vous permettent de créer des commandes rapides pour réexécuter des tâches courantes ou d'éliminer les implémentations internes en créant une interface claire, et agissent en tant qu'interface de script rapide.

J'adorerais savoir quels scripts vous avez construits et connaître les astuces que vous avez découvertes en construisant vos propres scripts npm !