Antichesse (o ^ω^ o)
Le salaire moyen d'un DevOps (5-10 ans d'XP) est de ~43,5 K€ brut / an sur Paris. Je suis ravie d'apprendre que nous offrons mieux que la moyenne dans notre entreprise.
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.
Qui ne pèse que quelques Mo ! Pour @Animal.
Via Kalvn.
Pour Animal
Je cite :
Culture
DevOps is mostly about breaking down barriers between teams. An enormous amount of time is wasted with tickets sitting in queues, or individuals writing handoff documentation for the person sitting right next to them. In pathological organizations it is unsafe to ask other people questions or to look for help outside of official channels. In healthy organizations, such behavior is rewarded and supported with inquiry into why existing processes fail. Fostering a safe environment for innovation and productivity is a key challenge for leadership and directly opposes our tribal managerial instincts.
AutomationPerhaps the most visible aspect of DevOps. Many people focus on the productivity gains (output per worker per hour) as the main reason to adopt DevOps. But automation is used not just to save time, but also prevent defects, create consistency, and enable self-service.
MeasurementHow can you have continuous improvement without the ability to measure improvement? How do you know if an automation task is worthwhile? Basing decisions on data, rather than instinct, leads to an objective, blameless path of improvement. Data should be transparent, accessible to all, meaningful, and able to be visualized in an ad hoc manner.
SharingKey the success of DevOps at any organization is sharing the tools, discoveries, and lessons. By finding people with similar needs across the organization, new opportunities to collaborate can be discovered, duplicate work can be eliminated, and a powerful sense of engagement can be created among the staff. Outside the organization, sharing tools and code with people in the community helps get new features implemented in open source software quickly. Conference participation leaves staff feeling energized and informed about new ways to innovate.
À lire pour plus tard.
Rappel
Maven Wrapper est un petit script à positionner à la racine de votre projet et qui vous permettra :
- De définir la bonne version de Maven avec laquelle vous pouvez builder votre projet.
- De récupérer automatiquement cette version
Problème
Pour exécuter vos commandes de build, il ne faut plus taper
mvn clean installmais
./mvnw clean installInconvénients :
- Le "./" a ajouter devant la commande est fastidieux.
- Si vous êtes dans un sous-module, vous devrez faire un "../mvnw clean install" et cela fait perdre du temps.
Solution
Elle est en trois phases :
-
Installer une version de Maven dans votre poste
- Sans l'ajouter à votre PATH
- Mais en créant la variable MAVEN_HOME
-
Ajouter le script suivant dans votre .bashrc
_build_mvnw_dir() {
echo "$1/mvnw"
}
_find_mvnw() {
currentDir=`pwd`
while [ "$currentDir" != "" ]; do
isMvnwDir=`_is_mvnw_dir "$currentDir"`
if [ "$isMvnwDir" == "true" ]; then
break
else
currentDir=`_get_parent_dir "$currentDir"`
fi
done
if [ "$currentDir" == "" ]; then
echo ""
else
_build_mvnw_dir "$currentDir"
fi
}
_get_parent_dir() {
echo "$currentDir" | sed "s|^\(.*\)/[^/.]*$|\1|"
}
_is_mvnw_dir() {
if [ -f "$1/mvnw" ]; then
echo "true"
else
echo "false"
fi
}
_mvn() {
mvnwPath=`_find_mvnw`
if [ "$mvnwPath" == "" ]; then
$MAVEN_HOME/bin/mvn $*
else
eval "$mvnwPath $*"
fi
}
- Ajouter l'alias suivant à votre .bash_aliases
alias mvn='_mvn'Fonctionnement
Utiliser Maven comme vous en avez l'habitude, le script va simplement utilise Maven Wrapper s'il est définit dans votre projet, sinon il utiliser l'installation "par défaut" que vous avez faite de Maven dans le répertoire $MAVEN_HOME.
La paternité du terme DevOps revient à un Belge du nom de Patrick Debois autour de 2009. Faisant suite à une frustration croissante lors de ses missions pour le compte du gouvernement belge à propos des conflits entre développeurs et administrateurs système.Historiquement, les DSI séparent les équipes de développement des équipes d'exploitation du SI (Operations en anglais d'où le Ops).Ces équipes ont des intérêts divergents, les développeurs souhaitent du changement (nouvelles technologies, nou...
Je pense que disposer d'un article comme celui-ci, qui pose les bases à avoir à chaque étape pour croître en maturité et devenir DevSecOps dans son ADN, doit pouvoir servir de plan au développement d'un petite société.
Comment définir la timezone de votre base MySQL
Modifier le fichier : /etc/mysql/mysql.conf.d/mysqld.cnf
default-time-zone='+00:00'A methodology for building modern, scalable, maintainable software-as-a-service apps.
À lire et à relire ! À destination de tous les Ops et DevOps.
Introduction
Comme vous le savez sûrement, il existe une légende sur internet congrue à l'arrivée de Maven 3 : il est possible d'écrire des pom en Yaml. Eh bien sachez que la chose n'est en rien une légende.
En effet, les versions Maven 3.x et supérieures recherchent - avant de lire le pom.xml - un fichier spécifique dans ./mvn/extensions.xml. Ce fichier va charger des extensions à Maven lui permettant de faire plus de choses.
L'idée est donc de demander à Maven de charger l'extension polyglot-yaml qui va ajouter à Maven la capacité d'interpréter du Yaml.
Mise en oeuvre
- À la racine de votre projet créez le répertoire ./mvn/
- Créez dans ce répertoire le fichier extensions.xml dont le contenu est le suivant :
<?xml version="1.0" encoding="UTF-8"?> <extensions> <extension> <groupId>io.takari.polyglot</groupId> <artifactId>polyglot-yaml</artifactId> <version>0.2.1</version> </extension> </extensions> - Créez un fichier pom.yml à la racine de votre projet
- A titre d'exemple, voici un modèle de pom parent en Yaml :
modelEncoding: 'UTF-8'
modelVersion: '4.0.0'
groupId: 'com.enterprise.fivestars.fs'
artifactId: 'fs-project'
version: '1.0.0-SNAPSHOT'
packaging: 'pom'
name: '. ${project.artifactId} [${project.version}]'
properties:
## Project encoding
project.encoding: 'UTF-8'
project.build.sourceEncoding: '${project.encoding}'
project.reporting.outputEncoding: '${project.encoding}'
## Maven compiler
maven.compiler.source: '1.8'
maven.compiler.target: '${maven.compiler.source}'
## Kotlin compiler
kotlin.compiler.jvmTarget: '${maven.compiler.source}'
kotlin.source.directory: '${project.basedir}/src/main/kt'
kotlin.test.directory: '${project.basedir}/src/test/kt'
kotlin.version: '1.1.51'
## Loggers
logback.version: '1.1.7'
slf4j.version: '1.7.22'
modules:
- fs-domain
- fs-main
- fs-persistence
dependencyManagement:
dependencies:
## Project dependencies
- { groupId: '${project.groupId}' , artifactId: 'fs-project' , version: '${project.version}' }
- { groupId: '${project.groupId}' , artifactId: 'fs-domain' , version: '${project.version}' }
- { groupId: '${project.groupId}' , artifactId: 'fs-persistence' , version: '${project.version}' }
## Database - Driver & embedded DB
- { groupId: 'com.h2database' , artifactId: 'h2' , version: '1.4.195' }
## Database - Database migration
- { groupId: 'org.flywaydb' , artifactId: 'flyway-core' , version: '4.2.0' }
## Database - Connection Pool
- { groupId: 'com.zaxxer' , artifactId: 'HikariCP' , version: '2.7.2' }
## Database - Persistence framework
- { groupId: 'org.javalite' , artifactId: 'activejdbc' , version: '1.4.13.j7' }
## Dependencies Injection
- { groupId: 'org.codejargon.feather' , artifactId: 'feather' , version: '1.0' }
## Kotlin - JVM & Collection compliance
- { groupId: 'org.jetbrains.kotlin' , artifactId: 'kotlin-stdlib' , version: '${kotlin.version}' }
- { groupId: 'org.jetbrains.kotlin' , artifactId: 'kotlin-stdlib-jre8' , version: '${kotlin.version}' }
## Logger - Logging framework facad
- { groupId: 'org.slf4j' , artifactId: 'slf4j-api' , version: '${slf4j.version}' }
## Logger - Logging framework
- { groupId: 'ch.qos.logback' , artifactId: 'logback-classic' , version: '${logback.version}' }
## Testing dependencies
- { groupId: 'org.assertj' , artifactId: 'assertj-core' , version: '3.8.0' }
- { groupId: 'org.jetbrains.kotlin' , artifactId: 'kotlin-test' , version: '${kotlin.version}' }
- { groupId: 'org.junit.platform' , artifactId: 'junit-platform-runner' , version: '1.0.1' }
- { groupId: 'org.mockito' , artifactId: 'mockito-core' , version: '2.12.0' }
build:
pluginManagement:
plugins:
## Compiler - Java (Prevent its execution because of Kotlin)
- artifactId: 'maven-compiler-plugin'
groupId: 'org.apache.maven.plugins'
version: '3.6.2'
configuration:
compilerArgs: {arg: '-Werror'}
encoding: '${project.build.sourceEncoding}'
fork: true
debug: false
optimize: true
showDeprecation: true
showWarnings: true
source: '${maven.compiler.source}'
target: '${maven.compiler.target}'
executions:
- goals:
id: 'default-compile'
phase: 'none'
- goals:
id: 'default-testCompile'
phase: 'none'
- goals: ['compile']
id: 'java-compile'
phase: 'compile'
- goals: ['testCompile']
id: 'java-test-compile'
phase: 'compile'
## Compiler - Kotlin
- artifactId: 'kotlin-maven-plugin'
groupId: 'org.jetbrains.kotlin'
version: '${kotlin.version}'
configuration:
nowarn: false
jvmTarget: '${kotlin.compiler.jvmTarget}'
executions:
- goals: ['compile']
id: 'compile'
phase: 'compile'
configuration:
sourceDirs: [
'${kotlin.source.directory}'
]
- goals: ['test-compile']
id: 'test-compile'
phase: 'test-compile'
configuration:
sourceDirs: [
'${kotlin.test.directory}'
]
## ActiveJDBC - Enrich entities bytecode
- artifactId: 'activejdbc-instrumentation'
groupId: 'org.javalite'
version: '1.4.13.j7'
executions:
- goals: ['instrument']
id: 'enrich-entities'
phase: 'process-classes'
## Quality - JaCoCo (Code coverage)
- artifactId: 'jacoco-maven-plugin'
groupId: 'org.jacoco'
version: '0.7.9'
executions:
- goals:
id: 'prepare-agent'
inherited: true
- goals:
id: 'report'
inherited: true
phase: 'prepare-package'Et la même chose avec un pom enfant :
modelEncoding: 'UTF-8'
modelVersion: '4.0.0'
parent:
groupId: 'com.enterprise.fivestars.fs'
artifactId: 'fs-project'
version: '1.0.0-SNAPSHOT'
relativePath: '../pom.yml'
artifactId: 'fs-persistence'
packaging: 'jar'
name: '${project.artifactId}'
dependencies:
## Kotlin - JVM & Collection compliance
- { groupId: 'org.jetbrains.kotlin' , artifactId: 'kotlin-stdlib' , scope: 'compile' }
- { groupId: 'org.jetbrains.kotlin' , artifactId: 'kotlin-stdlib-jre8' , scope: 'compile' }
## Database - Database migration
- { groupId: 'org.flywaydb' , artifactId: 'flyway-core' , scope: 'compile' }
## Database - Driver & embedded DB
- { groupId: 'com.h2database' , artifactId: 'h2' , scope: 'compile' }
## Database - Connection Pool
- { groupId: 'com.zaxxer' , artifactId: 'HikariCP' , scope: 'compile' }
## Logger - Logging framework facade
- { groupId: 'org.slf4j' , artifactId: 'slf4j-api' , scope: 'compile' }
## Logger - Logging framework
- { groupId: 'ch.qos.logback' , artifactId: 'logback-classic' , scope: 'compile' }
## Testing dependencies
- { groupId: 'org.assertj' , artifactId: 'assertj-core' , scope: 'test' }
- { groupId: 'org.jetbrains.kotlin' , artifactId: 'kotlin-test' , scope: 'test' }
- { groupId: 'org.junit.platform' , artifactId: 'junit-platform-runner' , scope: 'test' }
- { groupId: 'org.mockito' , artifactId: 'mockito-core' , scope: 'test' }
build:
plugins:
- { groupId: 'org.jetbrains.kotlin' , artifactId: 'kotlin-maven-plugin' }
- { groupId: 'org.apache.maven.plugins' , artifactId: 'maven-compiler-plugin' }
- { groupId: 'org.jacoco' , artifactId: 'jacoco-maven-plugin' }Et en prime, vous savez à présent compiler du Kotlin avec Maven.
Introduction Les métriques sont la partie la plus visible d'une architecture de supervision. Ce sont des données en général facile à récupérer et à stocker. Par conséquent, il arrive souvent qu'on n'investisse pas assez de temps dans la compréhension des données collectées, du pourquoi nous les collectons et ce que …
Transférer un clone GIT d'un serveur vers un autre (avec tout son historique)
git clone --mirror <URL to my OLD repo location>
cd <New directory where your OLD repo was cloned>
git remote set-url origin <URL to my NEW repo location>
git push -f originPrésentation sur le devops bizops
Rappel :
TypeScript est un langage libre développé Microsoft. Le but de TypeScript est de fournir un langage fortement typé, qui étende JavaScript et qui puisse être converti en JavaScript (normes ES5, ES2016 ou ES2017) afin d'éviter au développeur d'utiliser directement JavaScript et de produire un code JavaScript qui soit portable et utilisant toutes les optimisations du langage. On dit du compilateur TypeScript qu'il est un transpilateur car il converti du code source en un autre code source et non en instructions (binaire, assembleur, byte-code).
Comment qu'on install TypeScript ?
En passant par NPM ! En effet TypeScript est devenu un paquet NPM et est considéré comme une dépendance technique de votre projet JavaScript. Cette façon permet d'avoir une version du compilateur TypeScript par projet plutôt que d'une seule version unique commune à tous les développements.
Comment faire pour installer TypeScript avec Yarn ?
## Pour une installation locale à votre projet :
yarn add --dev typescriptJe recommande bien évidemment l'utilisation de Yarn en lieu et place de NPM ainsi qu'une installation locale pour éviter les conflits de version inter-projets.
Cependant, et comme je suis vraiment sympa, voici les commandes à taper pour installer TypeScript via NPM :
## Créer une installation global sur votre OS (disponible partout dans la ligne de commande) :
npm install -g typescript
## Créer une installation local à votre projet JS (accessible uniquement via la commande ./node_modules/typescript/bin/tsc) :
npm install --save-dev typescriptComment qu'on s'en sert ?
Il y a deux méthodes pour transpiler du code TypeScript :
- Soit nous saisissons une gigantesque ligne de commande que nous écrivons dans un script shell.
- Soit nous fabriquons un fichier tsconfig.json à la racine de notre répo, qui contient tout la configuration du compilateur et que TypeScript charge automatiquement lorsque l'on tape la commande tsc.
Je rappelle que je chercher à reproduire l'architecture de dossier spécifiée par la convention Maven :
. (root folder)
|__ src/
| |__ main/
| | |__ js/
| |
| |__ test/
| |__ js/
|
|__ target/Voici mon fichier :
{
"compilerOptions": {
// BUILD GLOBAL OPTIONS :
"module": "commonjs", // What kind of loading system should we use (CommonJS, AMD, etc).
"outDir": "./target/js", // Output directory
"sourceMap": false, // Create the source-map file help to debug TypeScript code while executing JS
"target": "ES5", // The aimed JS version (ES5, ES2016, ES2017 or ESNext
// BUILD OUTPUT :
"diagnostics": false, // Display no statistics about number of files, base code size, etc.
"pretty": true, // Display color in console for error, warning, etc.
// ENCODING
"charset": "utf8", // The targeted file encoding
"newLine": "lf", // File will use Line Feed as EOL character (Unix format)
// COMPILER BEHAVIOR :
"allowJs" : false, // Allow JS syntax
"preserveConstEnums": true, // 'const enum' are kept in generated code
"removeComments": true, // Comment removed from transpiled code
"emitDecoratorMetadata": true, // Test
"experimentalDecorators": true,
// COMPILER ENFORCING :
"noImplicitAny": true, // 'any' type is mandatory
"noImplicitThis": true, // Forbien to mix 'any' and 'this' in the same expression
"noImplicitReturns": true // Raise error is a 'return' is missing in part of a function
},
"include": [
"./src/main/js/**/*" // Pattern finding the TypeScript files
]
}L'un de mes posts précédents montrant le différentiel entre deux tsconfig.json DEV & PROD est disponible ICI
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é
Voici ma configuration pour le compilateur TypeScript à mettre dans le fichier tsconfig.json. La première à destination de la production (avec beaucoup de check et de contraintes) et la seconde à destination du mode développeur (qui autorise plus de chose afin d'exécuter les tests en continue) :
PROD configuration :
{
"compilerOptions": {
// BUILD GLOBAL OPTIONS :
"module": "commonjs",
"outDir": "./target/js",
"sourceMap": true,
"target": "ES5", // The aimed JS version (ES5, ES2016, ES2017 or ESNext
// BUILD OUTPUT :
"diagnostics": true,
"pretty": true,
// ENCODING
"charset": "utf8", // The targeted file encoding
"newLine": "lf", // File will use Line Feed as EOL character (Unix format)
// COMPILER BEHAVIOR :
"allowJs" : false, // Allow JS syntax
"preserveConstEnums": true, // 'const enum' are kept in generated code
"removeComments": true, // Comment removed from transpiled code
// COMPILER ENFORCING :
"noImplicitAny": true, // 'any' type is mandatory
"noImplicitThis": true, // Forbien to mix 'any' and 'this' in the same expression
"noImplicitReturns": true, // Raise error is a 'return' is missing in part of a function
"noUnusedLocals": true, // Report errors on unused locals
"noUnusedParameters": true // Report error on unused parameters
},
"include": [
"./src/main/**/*"
]
}DEV configuration :
{
"compilerOptions": {
// BUILD GLOBAL OPTIONS :
"module": "commonjs",
"outDir": "./target/js",
"sourceMap": true,
"target": "ES5", // The aimed JS version (ES5, ES2016, ES2017 or ESNext
// BUILD OUTPUT :
"diagnostics": true,
"pretty": true,
// ENCODING
"charset": "utf8", // The targeted file encoding
"newLine": "lf", // File will use Line Feed as EOL character (Unix format)
// COMPILER BEHAVIOR :
"allowJs" : false, // Allow JS syntax
"preserveConstEnums": true, // 'const enum' are kept in generated code
"removeComments": true, // Comment removed from transpiled code
// COMPILER ENFORCING :
"noImplicitAny": true, // 'any' type is mandatory
"noImplicitThis": true, // Forbien to mix 'any' and 'this' in the same expression
"noImplicitReturns": true // Raise error is a 'return' is missing in part of a function
},
"include": [
"./src/main/js/**/*"
]
}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.
Pas mal cet article, d'autant que j'entends des arguments comme ceux-là assez souvent au travail finalement.