Antichesse (o ^ω^ o)
Cela se fait en deux étapes
1) Correctement installer NPM en définissant l'emplacement du cache et des modules dans le fichier .npmrc comme expliqué ici.
2) Prenons un exemple :
- Si dans votre fichier .npmrc vous avez défini le cache à l'emplacement /opt/repositories/npm/cache.
- Alors saisissez la commande :
yarn config set yarn-offline-mirror "/opt/repositories/npm/cache" - Et voilà :D
Edit 4
Correction d'un bug avec le -dev et -uat (qui n'était pas interprété comme un mode prod).
Edit 3
J'ai ajouté le mode "mock" quand vous avec une conf browser-sync que vous souhaitez activer et qui mock votre serveur. Nous avons donc -m, -mock, --mock, toujours afin de convenir au plus grand nombre.
Edit 2
J'ai ajouté plusieurs options pour le mode production. Nous avons à présent -p, -prod, --prod, afin de convenir au plus grand nombre.
Edit
J'ai eu besoin de modifier le script pour qu'il prenne en compte l'option "-prod" afin de distinguer la production de bundle en mode DEV et en mode PROD.
Mon besoin
Pouvoir taper quelque chose comme : yarn install clean build run
Ma solution
Créer un petit script baptiser yr (parce que yarn c'est trop long à taper et que je suis fainéante) qui permette d’enchaîner les commandes yarn/npm sans effort tout en gérant le cas des commandes customs créées via l'attribut "scripts" du fichier package.json.
Le script :
#!/usr/bin/env bash
PARAMS="$*"
## Sanitize PARAMS with transformation
PARAMS=`echo "$PARAMS" |
sed "s/ -m / -mock /" |
sed "s/ -m$/ -mock/" |
sed "s/ --mock / -mock /" |
sed "s/ --mock$/ -mock/" |
sed "s/ -u / -uat /" |
sed "s/ -u$/ -uat/" |
sed "s/ --uat / -uat /" |
sed "s/ --uat$/ -uat/" |
sed "s/ -p / -prod /" |
sed "s/ -p$/ -prod/" |
sed "s/ --prod / -prod /" |
sed "s/ --prod$/ -prod/" `
## Add the yarn commands
YARN_COMMANDS=" access add autoclean bin cache check config create exec generate-lock-entry generateLockEntry global help import info init install licenses link list login logout node outdated owner pack publish remove run tag team unlink upgrade upgrade-interactive upgradeInteractive version versions why workspace workspaces "
detect_run_mode() {
runMode=""
match=`echo "$PARAMS" | grep -e " -prod"`
if [ "$runMode" == "" ] && [ "$match" != "" ]; then
runMode="-prod"
fi
match=`echo "$PARAMS" | grep -e " -uat"`
if [ "$runMode" == "" ] && [ "$match" != "" ]; then
runMode="-prod" # UAT = PROD
fi
match=`echo "$PARAMS" | grep -e " -mock"`
if [ "$runMode" == "" ] && [ "$match" != "" ]; then
runMode="-mock"
fi
echo "$runMode"
}
is_yarn_command() {
isCommand=`echo "$YARN_COMMANDS" | grep " $1 "`
if [ "$isCommand" == "" ]; then
echo "false"
else
echo "true"
fi
}
isYarnCommand=`is_yarn_command $1`
runMode=`detect_run_mode`
if [ "$isYarnCommand" == "true" ]; then
yarn $*
else
for param in $PARAMS; do
if [ "$param" != "$runMode" ]; then
yarn run $param $runMode
fi
done
fiComment s'en servir ?
Pour exécuter une commande basique du genre yarn add ou encore yarn install il faut taper :
yr add
# ou
yr installPour exécuter une commande custom dont l'invocation est yarn run my_custom_command il faudra taper :
yr my_custom_commandEn résumé : une syntaxe pour les contrôler toutes !
Pourquoi ce tuto ?
Grosso-modo je dois apprendre comment reproduire un build Maven mais en JS avec les outils JS qui vont bien ; et qui soient plus ou moins les standards de facto du moment (i.e en ce début 2017).
Définitions :
À quoi sert quel outil dans ce gloubi-boulga d'outils tous plus hypes les uns que les autres ?
NodeJS :
C'est une machine virtuelle qui permet de faire tourner du JavaScript côté serveur.
NPM :
C'est le gestionnaire de paquets permettant de récupérer les dépendances transitives de vos projets (façon Maven). Certains disent que NPM signifie Node Package Manager mais l'auteur atteste que non.
Yarn :
NPM c'est top, mais ça possède trois inconvénients :
- La ligne de commande pu des fesses.
- NPM ne sait pas mettre les paquets dans un répo local (comme le fait a contrario Maven), donc NPM passe son temps à re-télécharger les dépendances qu'il a déjà téléchargé pour le projet précédent.
- NPM ne gère pas le build concurrent (il n'est pas multi-threadé) donc le build rame (enfin tout est relatif #CompilationC++).
Yarn est un outils qui réponds à ces trois problématiques avec un chat tout mimi en guise de logo.
TypeScript :
C'est à la fois un langage mais également un compilateur éponyme. En gros, les mecs de Microchiotte se sont dits que JavaScript ça ne sentait pas bon des fesses (comme la ligne de commande de NPM) et qu'il valait mieux coder avec de vraies classes, des vrais namespaces, de vraies visibilités (public, private, etc) et une fois que tout ceci était correctement codé en TypeScript, ont transpile ce code en du JavaScript ; autrement dit on convertir le code du TypeScript dans une syntaxe cohérente et fortement typée, vers du JS (incohérent et faiblement typé) ; et comme cela plus besoin de se prendre la tête à connaître tous les hacks de ce langage merdique (une référence ici sur la merdicitude de JS et une autre là sur la retard community - ces deux articles sont pour toi Lenny).
Jasmine :
C'est un framework permettant d'écrire des tests en JavaScript. Ces derniers peuvent être au niveau unitaire (façon JUnit) ou fonctionnel / intégration (façon Cucumber). En général Jasmine est considéré comme faisant partie des framework destinés au BDD (mais bon, je ne suis pas d'accord).
Karma :
Un outil permettant de charger une suite de tests écrits en Jasmine ou en tout autre chose. Le concurrent le plus sérieux est MochaJS qui est une sorte de medley entre Karma et Jasmine, mais comme je n'ai pas encore eu le temps de l'étudier,que Karma à l'avantage d'être soutenu par les développeurs Google qui bossent sur Angular 2 et que j'ai déjà utilisé Jasmine par le passé... Bah Karma & Jasmine.
PhantomJS :
NodeJS permet d'exécuter du JavaScript côté serveur, et bien PhantomJS est un navigateur sans interface graphique permettant d'exécuter du JavaScript dans une console afin de le tester (ndr. en s'appuyant sur Jasmine et Karma). Vous vous doutez bien qu'un navigateur sans IHM est un navigateur ultra-rapide pour faire tourner du JS (sous-entendu parfait pour avoir des phases de run de TU rapides durant nos builds).
Webpack :
Webpack peut quasiment tout faire à l'aide de ses plugins mais l'idée ici est de s'en servir pour trois choses :
- Packager l'ensemble du JS dans un seul fichier qui soit unique.
- Minifier au taquet ce fichier packagé.
- Ne pas inclure dans le package minifié le code mort, c'est-à-dire les classes qui ne sont jamais chargées directement ou transitivement par la classe Main.
Et donc dans tout ça ? Et bien dans tout cela vous aurez donc un build JS qui va chercher les dépendances tout seul, qui respecte le cycle de vie de Maven, qui assure la séparation du code à livrer (les sources) du code à ne pas livrer (les plugins du build et le code des tests), qui centralise la production des binaires en un seul endroit et qui soit capable de releaser votre build (i.e fabriquer des tags et incrémenter le numéro de version). Pas mal hein ?
La suite des posts à lire figure ici (en cours de complétion) :
Je précise ici que je cherche à reproduire l'architecture de dossier et le life-cycle de Maven mais pour un projet NodeJS / Aurelia. Nous allons donc avoir ce type de dossiers :
. (root folder) # La racine du répo
|__ node_modules/ # Le répertoire des éléments téléchargés par NPM
|
|__ src/ # Le répertoire contenant les sources
| |__ main/ # Les sources qui seront livrées
| | |__ js/
| |
| |__ test/ # Les sources qui ne seront jamais livrées (les tests)
| |__ js/
|
|__ target/ # Le répertoire contenant les éléments générés lors de build
|
|_ karma.conf.js # Le fichier de configuration de Karma (le générateur de suite de tests)
|_ package.js # Le fichier de configuration de Yarn (le build manager)
|_ tsconfig.json # Le fichier de configuration de TypeScript (le transpilateur)
|_ webpack.config.js # Le fichier de configuration de Webpack (le packager / minifier)- Comment installer et configurer NodeJS & NPM
- Comment installer et configurer le transpilateur TypeScript ?
C'est partiiii #JoueLaCommeBarnabé
Un benchmark en Yarn et NPM qui montre que Yarn "ça trou le cul !". Yarn est vraiment plus rapide que NPM d'un facteur 2,5 à 25 !
Je résume ici : vous travaillez pour un grand groupe (aller au hasard une grosse banque) et vous devez utiliser yarn (un remake de npm mieux foutou). Jusque là aucun soucis sauf que le proxy de la grosse banque fait du man-in-the-middle aux yeux et à la vue de tout le monde. Donc yarn quand il veut choper des trucs pas forcément utiles en SSL (genre phantomjs, le bouzin qui fait juste tourner NOS TESTS UNITAIRES) bah il veut pas le p'tit chaton parce qu'il se rend bien compte que les mecs du proxy : ils font du man-in-the-middle comme des gros porcs.
Bref, voici comme détruire toute forme de sécurité dans yarn mais qui vous permettra (a minima momentanément) de récupérer des tools genre phantomjs :
yarn config set "strict-ssl" falseet pour restaurer la sécurité ce sera évidemment :
yarn config set "strict-ssl" trueVoici l'une de mes bonnes résolutions de l'année : faire des articles se servant de la mise en forme Markdown de mon Shaarli. Celui-ci sera la première partie - de ce qui je l'espère - sera d'une longue lignée.
NPM C'est quoi donc ?
NPM c'est d'abord un acronyme signifiant Node Package Manager ce que l'on peut traduire par "gestionnaire de package de Node JS".
Le fichier 'package.json' c'est quoi donc ?
Tout comme il existe chez Maven, un fichier pom.xml qui décrit un projet, il existe un fichier package.json qui fait la même chose en Node JS.
Ok donc dois-je me servir de NPM comme outil de build ?
Eh bien non, désolé. En réalité vous pourriez, cependant JavaScript étant ce qu'il est, l'écosystème bouge tellement vite que la norme à adopter c'est YARN.
Ok mais qu'est-ce que YARN aurait de plus que NPM et justifiant son usage ?
Pour comprendre cela, il faut comprendre ce que fait NPM
- NPM va d'une part gérer (c'est-à-dire télécharger et mettre à jour) vos dépendances et les dépendances de vos dépendances. Nous parlerons alors de *gestion transitive des dépendances.
- NPM est également en mesure d'exécuter des commandes que vous lui aurez indiquer. Cela vous permettre par exemple de transpiler une application, de la packager ou encore de la déployer.
Parfait mais qu'est-ce que ne fait pas NPM alors ?
Eh bien deux choses :
1) Il ne met rien en cache, c'est-à-dire que NPM va retélécharger encore et toujours chacune des librairies que vous avez utilisé dans vos projets ; contrairement à Maven qui stocke dans le répertoire
$HOME/.m2/repositoryl'ensemble des librairies dont vous vous êtes servi au moins une fois.
2) Il gère votre build de manière séquentielle, ce qui est dommageable en termes de performances étant donné que nos processeurs sont tous multi-cœurs voire multi-cœurs et hyper-threads à ce jour.
Et YARN est une surcouche de NPM qui répond tout simplement à ces deux besoins.