Antichesse (o ^ω^ o)
Je cite :
Le nouveau format de verrouillage des paquets déverrouillera la possibilité de faire des constructions reproductibles de manière déterministe et comprend tout ce dont npm aura besoin pour construire entièrement l'arbore des paquets. Avant que les fichiers yarn.lock de npm 7 ne soient ignorés, la CLI peut maintenant utiliser yarn.lock comme source de métadonnées de paquets et de conseils de résolution.
Imaginez que l'outil standard de construction des fronts en JS (l'outil de build si vous préférez) vient seulement de fournir la fonctionnalité de garantir un build reproductible...
Comment vous dire... Ça fait 7 ans, tous les fronts "pros" s'appuyaient dessus et nous sommes fin 2020...
Je résume la procédure :
rm -Rf ./node_modules
npm cache verify
npm cache clean --force
npm update
npm install
# EnjoyJe suis en train d'analyser le partie front du projet d'un client et j'ai le sentiment qu'une tripotée de dépendances y est tirée alors qu'elles ne sont pas utilisées. depcheck est un utilitaire qui lit votre package.json puis parcours votre code afin de déterminer si les dépendances déclarées sont bel et bien utilisées, sinon c'est que vous pouvez les mettre à la poubelle.
Les secrets des dépendances en JS.
Tout est dans le titre.
Comment récupérer le mot de passe ou le numéro de carte de crédit de quelqu'un en :
1) Développant un petit code malicieux de rien du tout.
2) Fabriquant une lib qui colorise les logs dans la console du navigateur pour que ça mettre en rouge les erreurs et en bleu les infos (fonctionnalité indispensable au demeurant).
3) Incluant le petit-code-malicieux dans la lib qui fait les logs.
4) En proposant à tout un tas de frameworks JS libres de la communauté NPM d'inclure "gratuitement" et "sans prise de tête" ce framework de logs en couleur.
=> Conclusion, depuis 2015, le répo NPM contient plusieurs frameworks infectés. #Noïce
Le petit rappel qui va bien :
NodeJS c'est quoi ?
NodeJS est une machine virtuelle capable d'exécuter des applications écrites en JavaScript côté serveur ; avec la capacité de démarrer un serveur web, de se connecter à une base de données, d'écrire sur le disque, etc. NodeJS est basé sur le moteur JavaScript développé pour WebKit et fournit sa propre implémentation du standard ECMAScript 6 (aka. ES2016), c'est-à-dire la dernière version standardisée de JavaScript en ce début 2017.
NPM c'est quoi ?
NPM est le gestionnaire de dépendances/paquets de NodeJS. Il est founi avec l'installation de NodeJS et utilisé par les développeurs pour télécharger, installer et exécuter l'ensemble des dépendances transitives de leurs projets JavaScript.
NPM peut :
- Gérer les dépendances pour les librairies s'exécutant côté client.
- Gérer les dépendances pour les librairies s'exécutant côté serveur.
- Exécuter des commandes dans la syntaxe du shell courant (et donc toutes les commandes figurant dans le path du-dit shell).
Comment qu'on setup toussa ?
1) Télécharger la dernière version (stable de préférence) de NodeJS
- La dernière version LTS (pour Long Term Support) est disponible ICI.
- Veillez à choisir la version compatible avec votre système, c'est-à-dire OS + architecture (32 ou 64 bits).
2) Installer NodeJS
Décompresser le tar.gz téléchargé dans un répertoire dédié, par exemple /tools/apps/nodejs-6.9.1.
Modifier votre fichier ~/.profile ou au choix ~/.bashrc comme suit :
- Créer la variable d'environnement $NODE_HOME
export NODE_HOME="/tools/apps/nodejs-6.9.1" - Ajouter le sous-répertoire $NODE_HOME/bin/ dans votre path système :
export PATH="$PATH:$NODE_HOME/bin" - Veillez à bien enregistrer les changements et redémarrer votre console si vous avez modifié le fichier ~/.bashrc et votre session pour le fichier ~/.profile.
- Hop vous avez à présent NPM et NodeJS disponible sous les commandes npm et node depuis un shell.
3) Configurer NPM
N.B : Dans la suite, le répertoire /tools/repositories peut en réalité être celui de votre choix. Moi je stocke tout dans /tools (en fait dans /opt/tools mais on s'en fiche).
- Nous allons dire à NPM où stocker les versions zippées des librairies qu'il a téléchargé, pour cela il faut ajouter/modifier la ligne suivante dans le fichier ~/.npmrc.
cache="/tools/repositories/npm/cache" - Ensuite nous allons indiquer à NPM où décompresser les librairies télécharger au point précédent en ajoutant au fichier ~/.npmrc
prefix="/tools/repositories/npm/modules" - Modifier votre fichier ~/.profile ou au choix ~/.bashrc comme suit :
export NPM_MODULES="/tools/repositories/npm/modules" export PATH="$PATH:$NPM_MODULES/bin" - Et encore une fois veillez à bien enregistrer les changements et redémarrer votre console si vous avez modifié le fichier ~/.bashrc et votre session pour le fichier ~/.profile.
4) Dis-nous comment ça marche en moins de 60 secondes ?
## Télécharger un outil et l'installer dans le répertoire global contenant les modules, par exemple Gulp :
npm install -g gulp
## Exécuter Gulp en tapant
gulp --version
## Télécharger un outil et l'installer uniquement pour votre projet (i.e dans le sous-répertoire ./node_modules):
npm install --save-dev gulp
## Exécuter Gulp en tapant
./node_modules/gulp/bin/gulp --version
## NDR : des fois il faut taper ceci à la place
node ./node_modules/gulp/bin/gulp.js --version
## Installer une librairie en tant que dépendance de votre projet (elle sera mise dans le répertoire ./node_modules).
npm install -save aurelia-framework
## Installer une librairie qui ne sera pas livrée avec votre projet (par exemple un framework de test) :
npm install --save-dev jasmineEt voilà en prime le lien vers le site officiel de NPM :D
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 !
Un tuto pour faire du NPM + WebPack + TypeScript + React. Je ferai un résumé de la conf plus tard (si j'ai le temps).
Voici 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.
Tout ce que vous devez savoir sur NPM notamment (dans la section CLI) la liste des paramètres de la ligne de commande
Une sorte de tutoriel sur ReactJS et sa stack technique (babel, npm...)
Tuto de déploiement avec Travis CI