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...
— Liens directs
Je résume la procédure :
rm -Rf ./node_modules
npm cache verify
npm cache clean --force
npm update
npm install
# Enjoy
]]>Je 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.
— Liens directs
Les secrets des dépendances en JS.
— Liens directs
Tout est dans le titre.
— Liens directs
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
]]>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 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 :
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 :
export NODE_HOME="/tools/apps/nodejs-6.9.1"
export PATH="$PATH:$NODE_HOME/bin"
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).
cache="/tools/repositories/npm/cache"
prefix="/tools/repositories/npm/modules"
export NPM_MODULES="/tools/repositories/npm/modules"
export PATH="$PATH:$NPM_MODULES/bin"
## 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 jasmine
Et voilà en prime le lien vers le site officiel de NPM :D
— Liens directs
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).
À 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 :
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 :
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 ?
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)
C'est partiiii #JoueLaCommeBarnabé
— Liens directs
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 !
— Liens directs
Un tuto pour faire du NPM + WebPack + TypeScript + React. Je ferai un résumé de la conf plus tard (si j'ai le temps).
— Liens directs
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 d'abord un acronyme signifiant Node Package Manager ce que l'on peut traduire par "gestionnaire de package de Node JS".
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.
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.
Pour comprendre cela, il faut comprendre ce que fait NPM
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/repository
l'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.
— Liens directs
Tout ce que vous devez savoir sur NPM notamment (dans la section CLI) la liste des paramètres de la ligne de commande
— Liens directs
Une sorte de tutoriel sur ReactJS et sa stack technique (babel, npm...)
— Liens directs
Tuto de déploiement avec Travis CI
— Liens directs