Menu
Menu

Nous contacter

01 82 83 51 70 infos@globalis-ms.com

6B rue Auguste Vitu

75015 Paris, France

Mise en place d’un starter front-end

Tribune Glob'codeur

Le 12 septembre 2016 par Nicolas Torres

« Retour

Un kit de démarrage, sous licence MIT, versatile et simple d’usage pour le développement front.

bootstrap

La création d’un modèle unifié de développement front-end est devenu une nécessité au sein de GLOBALIS. La problématique est que chaque lead developer a ses propres outils de build pour le back-end et ses propres workflows selon le type de framework (Carbone, CodeIgniter, WordPress…). Le front-end est alors souvent mélangé à cette organisation à l’installation parfois complexe, ce qui rend les passations longues, devenant un frein aux interventions ponctuelles de développeurs extérieurs au projet.

C’est pourquoi nous avons créé un “Front starter”, kit de démarrage pour le développement front-end, suffisamment versatile pour s’intégrer aux différentes organisations de projet, et simple d’usage pour permettre à tous, spécialisés ou non en front-end, d’être rapidement opérationnels sur cet aspect.

Le Front starter est publié sous licence MIT et disponible sur Github


Dépendances

bower

Au vu de l’anatomie relativement homogène des projets du pôle “Réalisation d’application Web et mobile”, il est naturel que ce starter soit basé sur Bootstrap et jQuery. Pour éviter toute rigidité de Bootstrap, c’est sa version Bootstrap-SASS qui est embarquée. Son style peut être alors facilement adapté aux besoins du projet grâce à sa feuille de variables, ainsi qu’à la disponibilité de ses composants.

SASS est communément utilisé chez GLOBALIS pour ses nombreux avantages, préféré sous sa syntaxe SCSS plus lisible et rétro-compatible CSS. JavaScript est compilé et fusionné grâce à UglifyJS directement, le projet d’origine sur lequel reposent beaucoup d’outils.

Les dépendances sont gérées avec le package manager Bower, très simple à appréhender.


Outils de build

npm

Les build tools sont les outils nécessaires pour compiler les fichiers SCSS, et fusionner les fichiers JavaScript. Trois modes de compilation sont prévus :

  1. la compilation (update) met à jour les fichiers après installation ou git pull,
  2. la compilation continue (watch) est pour le développement,
  3. la compilation finale (build) minifie les fichiers pour le déploiement.

Contrairement aux tendances qui portent vers Gulp, Grunt ou encore Webpack, le Front starter exécute ses tâches via le task runner incorporé nativement dans Node.js : NPM run-script. Il permet d’automatiser des tâches répétitives comme la compilation, ou encore le renommage/déplacement de fichiers et globalement tout ce qui est script Shell. Ce choix évite une nouvelle abstraction plus lente et souvent disproportionnée pour nos réalisations.


Conventions

Le Front starter propose un lot de conventions et bonnes pratiques qui permettent de rester cohérent sur l’ensemble du code au fur et à mesure que le projet avance.

Le JavaScript est décomposé en composants unitaires et indépendants, tant pour les plugins jQuery sur-mesure que pour les développements en JS pur. Le style, quant à lui, suit l’arborescence décrite par le 7-1 pattern de Sass Guidelines qui offre une extensivité robuste pour les projets d’envergure. Une convention de nommage inspirée de BEM est également en vigueur, assurant la cohérence de la logique de style tant côté HTML que CSS.

google_icons

Le choix d’icônes de Bootstrap 3 étant très limité, on le supplémente de l’excellent Icomoon, qui permet non seulement de sélectionner des icônes parmi de nombreux packs gratuits et de qualité (notamment Material de Google), mais aussi d’ajouter des icônes personnelles, de modifier les dimensions et le positionnement des icônes une à une, et enfin d’importer et d’exporter notre sélection par projet, simplifiant la manipulation du pack par plusieurs développeurs.

Tout cela est détaillé dans le fichier README, qui est amené à évoluer, et surtout à être modifié au sein même d’un projet avec les modifications spécifiques à celui-ci.

Côté serveur (PHP), aucun design pattern n’est imposé car cela dépend du degré de dépendance du front-end vis-à-vis back-end : selon les besoins il peut être nécessaire soit de dissocier complètement les développements, soit de le greffer directement au moteur de rendu back-end.


Le développement web n’a jamais eu autant d’outils d’automatisation et de structure à sa disposition qu’aujourd’hui, jusqu’à parfois s’y perdre. Beaucoup des outils et méthodes mis en place ici sont des partis pris au milieu de cette impondérable masse de solutions, en gardant en tête qu’ils peuvent évoluer en fonction des usages et des technologies. Ceci étant, le Front starter, grâce à ses faibles dépendances, son arborescence transparente, et son périmètre restreint, répond aux contraintes internes et à ses objectifs : il est simple, versatile et évolutif.

Article précédent Article suivant