Le document traite des outils et technologies nécessaires pour gérer une chaîne d'outils front-end moderne en 2016, mettant en avant la nécessité de transpiler le code ES6 pour le rendre compatible avec les navigateurs. Il présente également une transition vers Webpack, soulignant ses avantages par rapport à Browserify, notamment le support des modules et une gestion simplifiée des dépendances. Des problématiques pratiques liées à la gestion des ressources et à la génération d'applications standalone à l'aide de Docker sont également abordées.

1. systematic
Compile ton Javascript proprement

2. Ce que l’on veut d’une toolchain Front-end en 2016
De nombreuses exigences!
Transpiler le code ES6/ES-next pour fonctionner dans les navigateurs d’aujourd’hui :
• Support syntaxe ES6: destructuring, default args, arrow functions, template strings…
• Support de “require” (CommonJS) et surtout de “import” (ES6)
Gestion des assets dans le projet et ses dépendances (CSS, polices, images, templates...)
• Approche composant facile à mettre en place
• Pipeline de preprocessing (sass, postcss, jade...) simple
Gestion des traductions
• Détection des chaînes à traduire, dans le code HTML/JS/ES6/Jade
• Export des traductions dans un format standard

3. La réponse: TADAAAAAAAAA !! blease-js
Ça fonctionne ! *
* Pour les applications standalone uniquement. Presque. En moche.

4. Les problèmes de blease-js
De la place pour des améliorations!
• Browserify a ses limites : pas d’imports es6, debug complexe. Pas de deep inspection.
• Approche composants pénible à mettre en place : les assets ne sont pas LOCAUX au code, à
ajouter explicitement dans le Gruntfile/gulpfile/Makefile…
• Grande difficulté à faire des libs : dépendances impossibles à exclure ou à aliaser, “chunking” à
réaliser à la main, pas de wrapping AMD/CommonJS/UMD à la demande
• Fortement lié à Angular; impossible en l’état de faire une application VueJS/React/…
Exemple (code réel) :
require('bluetils-js/lib/reload') // bluetils-js can’t be compiled, it’s just ES6 in a different folder
// Don't forget to import css in the HTML
// Don't forget to copy locals, images and templates in dist folder with the Makefile

5. Introduction à Webpack: “import” sous stéroïdes

6. Les avantages de Webpack
Petit effet It just worksTM
• Support des modules AMD, CommonJS, ES6...
• Peut importer (preque) tout type de fichier avec des préprocesseurs
• Génère facilement plusieurs chunks
• Possède un mode pour générer des bibliothèques, avec des wrappers permettant l’import
• Configuration courte mais pas non plus triviale
Exemple :
// Place l’objet dans la variable reload.
// Cette fois le module “reload” contient ses templates et styles !
import {reload} from 'bluetils-js'

7. Les imports avec WebPack
Bootstrap d’une app : simple et explicite
import {framework} from 'framework-js' // es6 import (named style)
import './style.scss' // add a <style> tag to the header
import tmpl from './templates/reload.jade' // put the content as a template function in tmpl
console.log(tmpl()) // <div class="reload"><span>Version v...
framework.configureApp(tmpl, ...)

8. Les nouveautés de Systematic
Webpack remplace Browserify.
Finies les manipulations de variables de Makefile.
• Les options sont définies dans le systematic.ini du projet
Fonctionne avec n’importe quel framework.
• Le projet choisit un profil (vanilla, angular, react…)
• Makefile spécifique à ce type dans Systematic, en plus du Makefile générique.
Type de projet : application ou library
• library permet d’être importé; les dépendances (angular, jquery…) n’y sont pas incluses.
• application permet de générer un bundle avec toutes les dépendances.
Les tests sont effectués en coopération avec le launcher Karma.

9. Un des problèmes rencontrés: le SASS glouton.
Les imports SASS sont dangereux; ils peuvent importer l’intégralité du CSS de Bootstrap, par
exemple, pour définir une seule classe. Exemple:
@import ‘font-awesome’;
.my-icon {
.fa;
.fa-wheel;
color: blue;
} // ⇒ Le fichier CSS résultant contient l’intégralité de font-awesome, plus une classe.
Solution : cassets, un paquet spécifique d’assets réutilisables.
• Contient à la fois des sources SASS et des fichiers CSS générés (utilisables depuis les SI)
• Contient les définitions de couleurs de BlueSolutions, les images génériques, ...
• Les fichiers SASS sont repensés pour ne PAS inclure tout l’univers une fois compilés (mixins)
Pas de sens de garder dans bluetils-js les définitions de polices, de style, d’images communes !

10. Les autres problèmes philosophiques rencontrés (et résolus)
• Les images statiques: comment faire pour ne pas avoir à les copier depuis des libs ?
• Standardiser les exports dans les bibliothèques / sous-bibliothèques
• Générer / charger des traductions depuis le code source avec easygettext
• Traduire de la même manière des applications Angular ou VueJS ou React ou Vanilla
• Passer outre la nature sournoisement “globale” d’Angular
• Bootstrapper des applications générées en externe, dans une template Angular
• Architecture d’un package: ce qui est sur Github, ce qui est sur NPM
• Utiliser PostCSS + CSSNext pour écrire le CSS du futur aujourd’hui
• Le local CSS: comment ne pas détruire la UI du composant voisin
=> Autant de futures présentations ou articles de blog !

11. Applications standalone: génération d’une image Docker
Une image légère et simple
• Basée sur la distribution alpine
docker.polydev.blue/sales-ui 0.8.0-alpine c33a39b82208 9 weeks ago 25.63 MB
• Contient uniquement les fichiers générés (ceux du package NPM)
• Contient uniquement NGINX pour servir les statics et effectuer le cache busting.
• Le fichier de settings JS est généré par l’entrypoint depuis les .ini montés dans le conteneur.

12. Merci
Des questions ?