Brunch presentation

gistfile1.txt

Brunch ?! C’est quoi, Brunch ?

Avec environ 4 000 stars GitHub (44% de Grunt), 270 forks et 4 ans d’existence active, il est tout sauf faiblard, juste… discret.



Brunch est un builder. Pas un exécuteur de tâches générique, mais un outil spécialisé dans la production de fichiers finaux pour la production, à partir de tout un tas de fichiers de développement.


Exécuteurs de tâches vs. outils de build

Brunch est fondamentalement spécialisé dans le build d’assets, ces fichiers qui seront utilisés à terme par la plate-forme d’exécution, en général le navigateur. Il fournit donc d’entrée de jeu un certain nombre de comportements et fonctionnalités. On y trouve notamment :

la catégorisation des fichiers sources : JavaScript, Feuilles de style, Templates ou « divers » ;
la concaténation intelligente de ces fichiers vers un ou plusieurs fichiers cibles ;
l’enrobage en modules des fichiers catégorisés JavaScript ;
la production des source maps associées ;
la minification des fichiers produits si on est en « mode production » ;
la surveillance des fichiers sources pour mettre à jour le build à la volée.

Brunch est une pipeline.

Mais toutes les pipelines ne sont pas égales, et leurs performances peuvent différer considérablement. Ainsi, Gulp reste beaucoup trop lent pour une utilisation « watcher » confortable, alors que Brunch et Glou, notamment, peuvent être extrêmement rapides.

Convention Over Configuration

minimise le code ou la configuration nécessaire


Cette mise à jour peut elle aussi avoir deux approches distinctes : soit elle reconstruit tout à partir du début (ce qui ne nécessite aucune connaissance particulière de la sémantique des tâches concernées), soit elle ne relance que les étapes de construction nécessaires au vu des modifications constatées, pour minimiser le travail de mise à jour.

Des plugins existent pour Gulp, mais leur configuration appropriée est semble-t-il souvent complexe, pour des résultats sous-optimaux.

plus de temps à regarder la console de leur outil 
La boucle de feedback < 300ms

Concaténer les fichiers, par catégorie, vers une ou plusieurs destinations que vous définissez ;
Déposer les résultats dans un dossier cible, accompagnés de fichiers et répertoires statiques que vous auriez posés au bon endroit source ;
Enrober ceux de vos JS sources qui le prévoient en modules CommonJS (pendant la phase de concaténation) ;
Produire les source maps nécessaires pour pouvoir déboguer dans votre navigateur sur base des contenus d’origine, non des concaténations ;
Surveiller vos fichiers et dossiers sources pour réaliser une mise à jour incrémentale du build à la moindre modification (si vous le lancez en mode surveillance plutôt qu’en build unique) ;
Fournir un serveur HTTP statique mais malin pour vos fichiers (si vous lui demandez).


Brunch fait par défaut attention aux dossiers suivants :

app contient toute la partie source, à l’exception des fichiers JS fournis par des tiers et non conçus pour être enrobés en modules. On y trouverait donc, dans les sous-dossiers de votre choix (ou à même app), des fichiers scripts, feuilles de style, et fichiers templates.
Tout dossier assets (généralement juste app/assets) verra son contenu copié-collé (récursivement) dans le dossier cible, tel quel, sans aucun traitement.
Tout dossier vendor (généralement à côté du dossier app) sera concaténé comme app, à un gros détail près : les fichiers scripts ne seront pas enrobés en modules. On y met donc généralement les bibliothèques tierces 100% front qui n’auraient pas de chargeur intégré type UMD, ou simplement que notre code utilise encore (pour le moment ;-)) comme un bon vieux global, au lieu de faire des require(…).
Tout fichier démarrant par un underscore (_) est considéré comme un fichier partiel, inclus par un autre, et ne sera pas utilisé de façon autonome.
public est le dossier cible par défaut. On retrouve là la convention de nombre de micro-serveurs type Rack et consorts.``

Enrobage CommonJS, Sourcemaps

Au passage, il est également possible d’être notifié