Fly, un système de build nouvelle génération

Qui se base sur la norme ECMAScript 6

Le 2015-07-02 17:01:29, par SylvainPV, Rédacteur/Modérateur

Depuis l'arrivée de GruntJS puis de Gulp, les lanceurs de tâches ou task runners sont de plus en plus utilisés pour gérer les tâches récurrentes dans la gestion et le déploiement de projets web. Ils permettent entre autres de travailler plus facilement avec des langages alternatifs comme TypeScript ou Dart, avec des préprocesseurs CSS comme Sass ou LESS, de vérifier la qualité du code et de lancer des tests unitaires à la volée. Leur succès a ouvert la voie à d'autres solutions similaires : Broccoli, Brunch, Cake... de quoi satisfaire tous les goûts.

Un nouveau projet vient d'apparaître récemment sur Github, se décrivant comme le système de build nouvelle génération. Fly repose en effet sur les générateurs et les promesses introduites par la norme ECMAScript 6 (alias ES 2015). L'utilisation de ces nouveautés permet d'obtenir une API quasi transparente, où les tâches sont décrites simplement comme un module exportant une fonction. On retrouve ainsi une syntaxe similaire aux steams de Gulp, mais beaucoup plus claire et concise.

Exemple de Flyfile :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
const paths = {  
  scripts: ["src/**/*.js", "!src/ignore/**/*.js"]
}

exports.default = function* () {
  yield this.tasks.clean()
  yield this.tasks.scripts()
  yield this.watch([paths.scripts])
}

exports.clear = function* () {
  yield this.clear("build")
}

exports.scripts = function* () {
  yield this
    .source(paths.scripts)
    .babel({/* options */})
    .uglify({/* options */})
    .concat("all.min.js")
    .target("build/js")
}

À noter que la future syntaxe async / await à l'étude pour la norme ECMAScript 7 (alias ES 2016) est également prévue et devrait être indiquée dans la documentation prochainement.

Le projet est encore très jeune, mais il donne un bon aperçu des nouvelles possibilités offertes par ES6/ES7. En limitant les tâches à de simples modules retournant une fonction, Fly devrait simplifier l'écriture de tâches et surtout favoriser leur interopérabilité. En effet, la multiplication des task runners n'a pas vraiment permis de standardiser la notion de tâche. Beaucoup choisissent encore leur système de build selon le nombre de modules disponibles, malgré diverses solutions d'adapteurs pour migrer de l'un vers l'autre. On peut espérer que les modules ES6 s'imposent d'eux-mêmes à ce titre de standard, et soient utilisables par tous les task runners populaires.

Fly s'exécute sur NodeJS et est distribué sous licence MIT. L'auteur du projet et principal contributeur est Jorge Bucaran, connu pour être l'organisateur des meetup TokyoJS.

Répertoire Github du projet.

Et vous ?

Utilisez-vous un système de build et lequel ?
Que pensez-vous de l'utilisation des générateurs ES6 pour ce type de solutions ?

Discussion forum

5 commentaires

jerho

Candidat au Club

Comme le dit l'auteur :

Code :

 syntaxe similaire aux steams de Gulp, mais beaucoup plus claire et concise

Avec Gulp, cela donne la syntax suivante :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
var paths = {  
  scripts: ["src/**/*.js", "!src/ignore/**/*.js"]
};

gulp.task('default', ['clear', 'scripts']);

gulp.watch(paths.scripts, ['default']);

gulp.task('clear', function() {
  del(['build']);
});

gulp.task('scripts', function() {
    source(paths.scripts)
    .babel({/* options */})
    .uglify({/* options */})
    .concat("all.min.js")
    .target("build/js")
});

Au vu de l'article rien de révolutionnaire par rapport à gulp.

Pour te répondre DonQuiche, les systèmes de build fonctionnent tous à peu près de la même façon :

1- tu déclares les traitements (gulp.task('script') || exports.scripts
2- tu déclares tes écouteurs gulp.watch || this.watch
3- tu déclares un module "default"
4- tu lance le builder en ligne de commande à la racine de ton projet

Ensuite, lorsqu'un fichier qui est en écoute (watch) est modifié, cela déclenche les traitements qui lui sont associés.

Donc, as ta question :

Code :

pourquoi retourner des tâches plutôt qu'executer des tâches ?

Ca permet au système de build de les exécuter à chaque modification des fichiers.

le 15/07/2015 à 20:30

DonQuiche
Expert confirmé

Pour les pratiquants de JS j'ai une question svp : pourquoi retourner des tâches plutôt qu'exécuter des tâches ?

Je connais peu l'environnement JS et les outils cités, et ça m'intéresse. L'utilisation de tâches se défend dans les systèmes déclaratifs où les tâches servent d'unité de contrôle du flux (via la spécification des conditions déclenchant automatiquement leur exécution). Mais ça ne me semble pas avoir d'intérêt dans un langage de programmation impératif comme JS.

le 15/07/2015 à 19:19
DonQuiche
Expert confirmé

Envoyé par jerho

Ca permet au système de build de les exécuter à chaque modification des fichiers.

Merci à toi pour cette réponse claire et proprement contextualisée.

le 15/07/2015 à 20:38
lechtitseb
Membre à l'essai

Comme l'article le fait justement remarquer, il y a énormément de nouveaux arrivants dans le domaine des build tools pour le Web.
Personnellement je suis très satisfait de Gulp jusqu'à présent car il me permet d'exprimer de manière assez concise ce que je veux faire, gérer les erreurs et au final offre une très grande souplesse.
Pour ceux qu'ES2015, ES2016 et + tentent, il faut savoir qu'on peut à présent (depuis Gulp 3.9.0) créer un gulpfile.babel.js qui permet de tirer parti de fonctionnalités comme les arrow functions...

Et pour les aventureux, apparemment il est aussi possible d'utiliser du TypeScript pour décrire son build Gulp..

Dans tous les cas pour moi ce qui compte c'est un minimum de maturité car intégrer un outil tout beau tout nouveau mais que personne n'utilise sérieusement depuis un moment ça ne me met pas en confiance =)

le 23/07/2015 à 21:05
SylvainPV
Rédacteur/Modérateur

Oui c'est la même raison qui m'a poussé à rester sur Grunt et à ne pas passer sur Gulp, mais ça c'était il y a un an et depuis Gulp n'a fait que croître en popularité. Donc peut-être que j'aurais mieux fait de m'y mettre tout de suite plutôt qu'avoir une base de projets à maintenir sur Grunt (la migration vers Gulp étant trop complexe et trop peu utile à ce stade). Je ne peux pas prédire si Fly aura du succès mais le fait qu'il repose sur les modules ES6 et yield/async/await présente beaucoup de sens selon moi, et constitue une raison valide pour tenter le coup. Bien sûr, Fly n'est pas encore assez mature pour les projets pros, mais le rythme de développement est rapide. La dernière version publiée est la 0.3.4

le 26/07/2015 à 15:33