Écrire des scripts npm multi-plateforme

npm c’est très bien, j’ai complètement abandonné gulp, grunt, et consors, et je commence même à embrasser ma condition d’allergique au fichier de conf (le package.json sera mon unique tolérance). Bref, si comme moi votre « task runner » est npm, alors comme moi vous avez du vous heurter au cas des « autres » plateformes, celles qui n’ont pas les mêmes commandes que vous, voire pas de commande du tout pour ce que vous voulez faire… c’est-à-dire Windows et son shell de Néandertal. Voici donc une série de modules node qui résolvent ces questions.

Commandes de base

COPY vs cp, MKDIR vs mkdir -p, etc… les commandes de base ne sont pas acquises du tout, passez par des modules npm faits pour ça :

  • rm -rf filesrimraf files
  • cp -r source targetcpx source target (qui a en plus une option --watch pour maintenir la cible à jour)
  • mkdir -p a/b/cmkdirp a/b/c

Variables d’environnement

La syntaxe ENV_VAR=value commande sous Windows ne fonctionne pas.

  • Utilisez plutôt cross-env ENV_VAR=val command

Exécuter plusieurs commandes

  • Plusieurs scripts npm en parallèle :
    • npm run a & npm run b & npm run c & waitnpm-run-all --parallel a b c (plus court, plus solide, plus universel)
  • Plusieurs scripts npm en série :
    • npm run a && npm run b && npm run c fonctionne très bien, pas besoin d’outil sur ce coup
    • npm-run-all a b c sera plus concis
  • Plusieurs commandes hors scripts npm, en parallèle : aggregate-commands (mais autant mettre ces commandes en script npm et utiliser npm-run-all)

Commandes de « watch »

Aucune excuse !

Vous n’avez maintenant plus aucune excuse pour ne pas écrire de scripts de « build » qui tournent partout, sans pour autant vous encombrer de task-runners obèses. Vous en connaissez d’autres ? Commentez !

4 réflexions sur « Écrire des scripts npm multi-plateforme »

  1. Boris (@borisschapira)

    Je me retrouve bien dans la description, vu que j’ai passé plusieurs mois à basculer de Windows (pour le dév.) à Ubuntu et Debian (pour les serveurs). En revanche, ne passer QUE par npm pour le task running, je n’ai jamais réussi. J’ai en général un grunt ou un gulp pour ça (hautement configurable) mais derrière, je détermine les quelques tâches de build, package et deploy et j’abstrais le task runner derrière des commandes npm…

    Répondre
    1. naholyr Auteur de l’article

      Les tâches de build je n’en ai vraiment croisé aucune qui ne puisse se faire en simple CLI. Le deploy ça peut-être des besoins tellement plus spécifiques que tu finis souvent avec un script maison en effet. Mais le git push to deploy, ou un s3-upload, ce genre de choses finissent aussi souvent en one-line simples.

      Répondre
  2. Jeremie

    Pour ce que ça vaut:

    Pour l’accès au système de fichier (copies, suppression, création, etc.) fs-extra fait bien le boulot et évite d’avoir plusieurs modules pour ça.
    https://www.npmjs.com/package/fs-extra

    Pour exécuter plusieurs commandes, j’aime beaucoup paralleleshell qui évite plein de mauvaise surprise quand un process fail et pas les autres.
    https://www.npmjs.com/package/parallelshell

    Pour tout ce qui est watch, gaze se pose un peu là pour facilement faire du globing
    https://www.npmjs.com/package/gaze

    Après en ce qui me concerne j’ai plutôt tendance à écrire des fichier js que je transforme en commande npm plutot que de faire de la ligne de commande brute (mais bon après, c’est les gouts et les couleurs, hein).

    Répondre

Répondre à naholyr Annuler la réponse.

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.