IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

JavaScript Discussion :

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


Sujet :

JavaScript

  1. #1
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    Novembre 2012
    Messages
    3 375
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2012
    Messages : 3 375
    Par défaut Fly, un système de build nouvelle génération
    Fly, un système de build nouvelle génération
    qui se base sur la norme ECMAScript 6

    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.

    Nom : fly.png
Affichages : 5165
Taille : 14,2 Ko

    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 ?

  2. #2
    Membre Expert Avatar de DonQuiche
    Inscrit en
    Septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : Septembre 2010
    Messages : 2 741
    Par défaut
    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.

  3. #3
    Invité de passage
    Homme Profil pro
    Chef de projet en SSII
    Inscrit en
    Janvier 2015
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Vaucluse (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Chef de projet en SSII

    Informations forums :
    Inscription : Janvier 2015
    Messages : 1
    Par défaut
    Comme le dit l'auteur :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
     syntaxe similaire aux steams de Gulp, mais beaucoup plus claire et concise
    Avec Gulp, cela donne la syntax suivante :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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.

  4. #4
    Membre Expert Avatar de DonQuiche
    Inscrit en
    Septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : Septembre 2010
    Messages : 2 741
    Par défaut
    Citation Envoyé par jerho Voir le message
    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.

  5. #5
    Membre régulier
    Homme Profil pro
    Inscrit en
    Avril 2006
    Messages
    10
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : Avril 2006
    Messages : 10
    Par défaut
    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 =)

  6. #6
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    Novembre 2012
    Messages
    3 375
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2012
    Messages : 3 375
    Par défaut
    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

Discussions similaires

  1. Réponses: 1
    Dernier message: 13/02/2008, 00h09
  2. Incrémentation de la version du build à la génération
    Par stephane.julien dans le forum C#
    Réponses: 2
    Dernier message: 31/01/2008, 08h32
  3. Réponses: 3
    Dernier message: 09/03/2007, 20h15
  4. Mini Mix- le web nouvelle génération
    Par Betatesteur dans le forum Événements et Conférences
    Réponses: 1
    Dernier message: 16/10/2006, 06h51

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo