10e édition du SymfonyLive ! Retours sur l’événement Sensiolabs francophone annuel. Et quel événement !
Vendredi 30 mars, la 10è édition de la Symfony Live a pris fin après deux jours denses et riches. La promesse est tenue, ce doit être la 4ème année de suite que j’y participe en tant que spectateur et j’y trouve toujours ce plaisir particulier.
Cette année on a eu la chance de pouvoir y aller en groupe pour représenter notre société Altéis Groupe.
Je me souviens de ma première édition, seul, j’avais vécu l’expérience intensément sans pouvoir tout à fait l’exprimer autour de moi. Désormais, on partage en équipe l’événement et je crois pouvoir mesurer sur les visages des autres qu’ils ont vécu aussi pleinement que moi cette nouvelle édition.
Parmi nous, il y avait les semi-habitués, sereins quant à l’aspect qualitatif et il y avait les nouveaux qui ont découvert pour la première fois “l’événementiel made in Sensio”. Ces derniers sont faciles à reconnaître car ils ne se déplacent jamais sans leur smartphone pour être sûrs d’immortaliser la moindre surprise, chaque goodies, tous les kakemono ou toute rencontre avec l’un des contributeurs de notre cher écosystème.
On en rigole, on les charrie mais finalement on les regarde tendrement car ces photos on les a aussi tous dans la mémoire de nos téléphones datant des précédentes éditions.
Mais alors, au-delà du show, de l’événement et de l’effet Entertainment que nous propose Sensiolabs cette année ?
Le ton est donné par Fabien Potencier qui inaugure la journée avec la première keynote. L’ambiance et la philosophie sont alors fixées : DX.
Voici en essence le paradigme mis en avant que je retiens de ces 2 jours. Je le retiens car personnellement c’est la première fois que j’en entendais parler.
DX est l’acronyme de “Developper Experience”. Initialement j’étais plutôt sceptique car le mot sonne un peu comme un terme marketing et commercial. Cependant j’ai voulu vérifier de retour à la maison et éprouver les promesses faites.
L’objectif principal de cet article (et éventuellement de futurs) est de vous faire partager l’expérimentation post-conférence des différents composants ou nouveautés présentés dans le cadre du SFLive avec ici un focus particulier sur l’amélioration de “l’expérience développeur”.
Flex
Sujet principal de la présentation de la keynote de Fabien Potencier et SYMFONY Live oblige, je n’ai pas pu commencer par un autre sujet que FLEX.
Nul ne saurait mieux expliquer ce qu’est Flex que son géniteur, aussi je vous renvoie vers les différents blog posts (*) voire vers la vidéo du talk dès qu’elle sera disponible. (Pour info ou rappel, tous les talks seront disponibles prochainement sur la chaîne Youtube de Sensiolabs)
Pour l’expliquer dans mes termes, Flex est une surcouche à “composer” dont la vocation est de simplifier la phase de création d’un projet Symfony puis l’installation et l’intégration/configuration des packages dans notre projet.
Hop hop pas trop vite. J’ai failli oublier le tout premier changement qui intervient lors de la création d’un projet Symfony.
“L’installateur spécifique Symfony n’a plus de raison d’être”. C’est annoncé puis justifié par le fait qu’il est désormais possible d’initialiser un projet Symfony à partir de “composer” directement (comme nous le ferions pour n’importe quel projet PHP).
Jusqu’ici l’installateur Symfony faisait bien le job mais utiliser le packager de référence d’installation des dépendances “Composer” est plus developper-friendly (pas sûr que l’expression existe mais puisqu’on parle de DX pourquoi pas de DF ?) De plus pour les nomades comme moi qui changent d’ordinateurs comme de chemises, plus de questions à se poser, si Composer est à jour alors je suis à jour pour créer mon projet SF.
Comment cela fonctionne-t-il dans les faits ? Et bien aussi simplement que possible ; il suffit désormais de lancer la commande create-project et d’installer le package symfony/skeleton (**). Finie la Standard Edition et bienvenue au Skeleton !
Symfony/skeleton
Pour bien se rendre compte de ce que cela représente comme changement en terme de components / librairies et bundles packagés, j’ai repris la représentation de Fabien Potencier qui se trouve ici.
Lançons la commande d’installation du Skeleton:
On peut remarquer dans l’output de composer ici une autre nouveauté liée cette fois à Flex, le prefetching des packages (premier encadré orange sur l’image ci-dessus). Globalement, il s’agit de télécharger l’intégralité des packages avant leur installation plutôt de procéder aux téléchargement / installation de chaque package l’un à la suite de l’autre. On imagine aisément que les performances s’en ressentent et ça je ne dis jamais non !
En définitive, j’ai effectivement pu créer mon projet en quelques minutes (score plutôt correct pour la première fois et avec la connexion internet dont je disposais lors de l’installation). Cependant, je n’initialise pas des projets Symfony from scratch tous les jours (un jour qui sait ?!).
Il est à noter que Sensiolabs a ajouté dernièrement une seconde version d’installation à partir d’une version étendue disponible avec symfony/website-skeleton. Il s’agit d’une version beaucoup plus concrète destinée aux websites traditionnels. Pour s’en rendre compte, voici le début de l’ouput de la commande.
La DX Flex s’arrête là ?
Et bien non ! Si on observe un peu l’output de l’installation de symfony/skeleton, il semble s’être passé des choses après l’installation des packages en tant que tels.
On entre désormais dans le cœur de la raison d’être de Flex. L’utilisation de recettes (“recipes”) pour l’installation des packages. Sur l’image ci-dessus, on remarque que Flex nous indique avoir utilisé 4 recipes pour l’installation de certains packages.
C’est l’une des nouveautés majeures avec Flex, l’utilisation de “recipes”. Il ne s’agit ni plus ni moins que de fichiers de configuration qui permettent l’installation et surtout la configuration automatique des bundles. Flex va pouvoir à partir de ces recettes configurer automatiquement un bundle lors de son ajout dans le projet.
Mieux encore, Flex va pouvoir « désinstaller » un bundle facilement et surtout le « déconfigurer » dans le projet. Finie la recherche des configurations liées dans app/config.yml et des éventuelles autres dépendances pour désactiver un bundle inutile dans notre contexte projet. Quiconque ayant déjà essayé de désinstaller Twig dans un projet API-centric aimera particulièrement cette nouveauté ;)
Recipes
Petit arrêt sur les recipes. Il existe deux “catégories” de recipes ;
- Les “recipes officielles” maintenues directement par la Core team ; https://github.com/symfony/recipes
- Les “recipes “communautaires” qui concernent les repositories qui ne sont pas directement maintenus par la CT ; https://github.com/symfony/recipes-contrib
Vous pouvez trouver une liste exhaustive des recipes existantes à l’url : https://symfony.sh/
Dans ces recipes, on retrouve un fichier “manifest.json” (pattern habituel désormais) au sein duquel est regroupé un ensemble de configurations à destination de l’installateur Flex.
Un exemple simple pour avoir un premier aperçu des possibilités :
Assez naturellement on imagine ce à quoi sert chaque index :
- On déclare pour quel(s) environnement(s) le bundle est disponible
- On précise les répertoires à intégrer et leur destination dans l’arborescence projet
- On définit un alias destiné à l’installation avec Flex. (On reviendra sur ces alias plus tard)
Il n’y a pas de magie (ce que j’aime cette phrase quand il s’agit de développement), pour permettre à Flex d’installer / configurer puis désinstaller et “déconfigurer” un bundle, il y a deux axes principaux :
- les parameters (désormais dans le fichier .env, encore une practice commune adoptée, chouette !) sont intégrés dans un pattern pré-défini qui permet de savoir à quel bundle ils font référence. Ainsi, il suffit de préserver le pattern ###> pour permettre à Flex de travailler
- Les configurations sont répertoriées dans des yaml (***) spécifiques et distincts
Donc mon installation Symfony est finie ?
Et bien oui, avec ces éléments je dispose de ma stack Symfony pure prête à être customisée selon mes besoins.
Autre nouveauté (visible sur l’imp. ci-dessous), un ensemble d’informations a été ajouté à l’ouput de la console afin d’aiguiller les développeurs dans leur action.
Typiquement ici, l’output nous indique que nous pouvons lancer un mini serveur (pour rappel depuis PHP 5.4, PHP met à disposition à partir d’une ligne de commande un serveur web. Voir ici). Il nous est aussi proposé d’installer le component server de Symfony à partir de la ligne de commande “composer require server — dev”
Décomposons un minimum :
- “require” plutôt qu’install pour utiliser Flex
- “server”, alias définit pour le component symfony/web-server-bundle
- — dev pour préciser directement dans quel environnement je souhaite “enabled” le component
On retrouve ici la notion d’alias, il est temps d’en parler. Concrètement il s’agit de choix et donc préconisations faites par la Core Team par rapport à l’utilisation de bundles pour répondre à des besoins courants.
Ces alias sont définis dans les recettes présentées précédemment (uniquement celles maintenues par la Core Team). Leur objectif principal est donc d’aiguiller la communauté dans le choix de bundles parmi tout ceux proposés (orm => doctrine, api => api-platform …)
Pour être sûr qu’il ne s’agit pas simplement d’un trompe l’oeil, je cherche à lancer le serveur.
A noter que l’installation d’un bundle sans « recipe » officielle reste possible, cependant Flex ne pourra pas le configurer automatiquement (ni enlever la configuration liée en cas de désinstallation).
Pack / Unpack
Non, non il ne s’agit pas d’une déclinaison de webpack. C’est bien une des nouvelles features de Flex, la gestion de “pack”.
Globalement il s’agit pour Flex de packager des dépendances (bundles) entre elles pour en faire des “pack fonctionnels”. Un exemple simple ; lorsque l’on fait “composer req debug”, Flex nous permet de récupérer le package de débug pour notre application.
Il est bien précisé que “debug” est l’alias du pack “symfony/debug-pack”. On remarque que le pack comprend l’installation de 14 dépendances et l’utilisation de 5 recipes.
Là encore, on voit tout de suite l’intérêt apportée par la simplicité d’installation et de configuration.
Je souhaite pouvoir débugger simplement mon application, il me suffit alors d’en faire la demande à mon Flex favori :)
Cependant, si on s’aventure à regarder la mise à jour réalisée sur le fichier “composer.json”, on remarque que les 14 dépendances installées ici ne sont pas énumérées ; seul le pack est défini.
Pourquoi cela ? Si on cherche la recipe utilisée par Flex pour installer symfony/debug-pack sur le site dédié (pour rappel ici), on peut accéder au “Package details”
Alors on comprend tout de suite qu’un pack n’est ni plus ni moins qu’un “repository” référencé sur le site packagist qui définit ses propres “dépendances”.
Voilà donc d’où vient la définition de ce qu’est un “pack” en terme de dépendances.
Je pense que dans les faits, dans la majorité des cas, cela ne nous posera pas de problème particulier de référencer un ensemble de dépendances sous la forme d’une unique dépendance vers le “pack” correspondant. Cependant, il se peut que dans certains cas, nous ayons besoin de définir une version spécifique d’une dépendance voire de remplacer une brique par une autre.
C’est pour répondre à ce besoin précis que Flex a introduit une nouvelle feature ; l’unpacking. Globalement il s’agit de pouvoir décomposer les dépendances d’un pack après son installation.
Pour ce faire, il suffit de taper la commande “composer unpack debug”
Le “removing” peut être effrayant mais pas de panique ! Observons les évolutions du fichier composer.json
On remarque ici que symfony/debug-pack a disparu et que les dépendances sont devenues explicites (easy-log-handler, debug-bundle, monolog-bundle..).
Si vous voulez plus d’informations sur l’unpack, vous pouvez consulter l’article de Fabien Potencier sur le sujet.
En conclusion, la promesse DX semble être au rendez-vous au niveau de l’installation et de la configuration d’un projet Symfony. Il se dégage un vrai sentiment de légèreté, de FLEXibilité avec ce nouveau composant. Il m’arrive d’entendre que Symfony est lourd et ressemble à une machine de guerre peu souple incluant bien trop de composants.
Cela semble être en passe d’être de l’histoire ancienne !
On a ici une preuve de plus que Sensiolabs sait se montrer à l’écoute de son écosystème et de sa communauté pour nous apporter des nouveautés en parfaite cohérence avec nos demandes terrain et avec nos besoins concrets par rapport aux projets que nous avons à mener.
Ce que c’est plaisant !
Annotations
(*) Présentation officielle : http://fabien.potencier.org/symfony4-flex-update.html
(**) Il existe une variante. symfony/skeleton est la version minimaliste particulièrement pertinente dans le cadre de la création d’un projet API par exemple. Pour des applications Symfony plus “traditionnelle”, Sensiolabs a ajouté symfony/website-skeleton (et oui car c’est là la force de Sensiolabs, rester à l’écoute de l’écosystème, expérimenter puis modifier des décisions initiales si nécessaire)
(***) yml / yaml ? Fini de se poser la question, les best practices définissent désormais l’utilisation de yaml. Plus de question à se poser et comme on dit dans la philosophie Scrum “The consistency reduces complexity.”