Retour d’expérience : Steeplify, la librairie de composant Steeple construite avec Vue

Il y a 1 an et demi, nous étions 8 développeurs à construire l’écosystème Steeple et 3 développeurs front sur l’application web et l’application des tableaux d’affichage tactile.

À ce moment, l’architecture de la partie front de Steeple est un monolithe Nuxt2 qui implémente ces deux applications. Elles sont proches en termes de fonctionnalité : consultation de publication, interactions, modules, utilisateurs. On retrouve donc du code source utilisé par les 2 applications. C’est au moment de créer le bundle de l’application que l’on sépare les deux projets : steeple-web et steeple-tv.

Mais l’équipe a bien grandi et nous sommes maintenant 22 personnes (et un prévisionnel de 40 d’ici fin 2023).

Nous avons la nécessité que différentes équipes se partagent les missions sans se marcher dessus tout en évitant de re-développer des fonctions simples de Steeple.

Ces évolutions nous ont amené à une problématique majeure :

Comment maintenir du code nécessaire à la construction de deux applications distinctes ?

Nous avons ainsi décidé de suivre le fameux “Diviser pour mieux régner”. Créer deux projets totalement distinct répondant chacun à ses enjeux.

Et pour implémenter le code source commun à ces deux projets, une solution est apparue : la librairie de composants !

• Sommes-nous satisfaits de cette solution ?
• Répond-elle à toutes nos problématiques ?
• Quelles sont les bloquants ?

Dans cet article, nous allons répondre à toutes ces questions.

Avant de se lancer, nous avons évalué tous les risques de la mise en place d’une telle solution et nous avons décidé de partager notre phase de tests en deux parties :

• La création de la librairie
• Le test grandeur nature

Créer une librairie de composant

S’inspirer des autres

Nous ne sommes évidemment pas les premiers à avoir créé une librairie de composant et nous avons décidé de nous renseigner sur les solutions pour construire un tel projet.

Nous nous sommes basés sur Vuetify qui offre de nombreuses fonctionnalités (composants, breakpoint, grid, …) et qui possède une documentation complète. C’est une source d’inspiration sur de nombreux aspects et aussi concernant les composants qui proposent une multitude de propriétés.

Et à l’image de Vuetify, notre librairie s’appelera … (suspens et roulement de tambour) :

Steeplify !

Le choix des outils

Notre première mission est de choisir les outils que nous allons utiliser pour développer notre librairie.

Nous avons donc créé un cahier des charges listant les problématiques techniques auxquels la librairie doit répondre :

• Fonctionner dans un environnement en Server Side Rendering.
• Etre compatible avec les navigateurs et versions que nous supportons.
• Etre construite en Typrescript.
• Répondre aux enjeux de performance et fonctionner avec le Treeshaking
• Posséder une documentation complète pour les développeurs qui l’utiliseront
• Compatible Vue2
• Supporter Sass

La première étape est de choisir un Bundler. À l’époque où nous devons faire notre choix, il existe trois concurrents principaux : l’indétrônable Webpack, l’éternel Rollup et le tout nouveau Vite.

Aillant peu d’expérience sur les 3 outils, nous avons effectué des recherches sur les possibilités que chacun offre, la communauté présente autour de l’outil, les exemples proposés en lien avec notre projet. Notre choix s’est finalement porté sur Rollup.

L’idée étant de construire une librairie fonctionnelle et testable, Rollup possède un large choix de plugin pour le Server Side Rendering, la compatibilité Vue et Typescript, le support ES et CJS et d’autres.

Pour la documentation dynamique, c’est Storybook qui s’est imposé. Cet outil est très largement recommandé pour React et possède un support de Vue. Bien que l’outil ne possède pas une documentation très complète (un comble pour un outil de documentation), c’est celui qui répond le mieux à nos besoins et qui propose un large choix de fonctionnalités (Support MDX, Accessibilité, …).

Pour les choix des technologies de développement, vous l’aurez compris, nous avons décidé de rester simple en utilisant notre stack habituelle (Vue2, Typescript, Sass).

La structure de la librairie

La structure de la librairie est une étape importante dans sa construction, il existe des possibilités infinies et nous avons réfléchis à trois solutions.

Solution 1 : La scalabilité

Dans cette première structure, l’idée est de découper chaque composant, chaque directive en un package NPM. Cette solution permet de répondre aux problématiques de treeshaking brillamment. Grâce à Lerna, la gestion des paquets et le versionning est simplifié.

Malgré tout, la gestion des dépendances entre chaque paquet (slist > sbutton > ripple) deviendrait très vite un plat de spaghetti impossible à maintenir. En fait, cette structure serait plus adaptée à des projets ayant des paquets qui n’ont pas de lien direct entre eux, par exemple, les plugins rollup.

Solution 2 : La simplicité

La deuxième solution envisagée est beaucoup plus simple. Un dossier vient englober l’ensemble des composants et les tests à l’image d’un projet Vue classique. Cette solution porte bien son nom, car, pas d’organisation Monorepo ou de Lerna, un simple projet dans un dossier.

Nous décidons de ne pas utiliser cette solution qui nous paraît un peu fourre-tout, notamment avec la gestion des dépendances entre la librairie et la partie test et documentation (qui sont d’ailleurs séparés dans Vuetify).

Solution 3 : L’entre-deux

Cette solution nous permet de garder les avantages des deux premières solutions tout en limitant les inconvénients.

Le projet s’organise en 3 dossiers :

• La librairie
• Les tests
• La documentation Storybook

Le test grandeur nature

Steeplify v1 est opérationnel. C’est une grande nouvelle, la librairie peut être importé dans nos autres projets. Elle ne comporte qu’une petite dizaine de composants et quatre directives, mais nous allons pouvoir commencer notre phase de tests grandeur nature.

Comme aucun développeur n’a travaillé avec une architecture de ce type dans ses expériences précédentes, il nous faut valider l’expérience développeur d’un tel système.

Nous avons validé techniquement le projet, mais il ne faut pas négliger l’expérience développeur qui inclut la facilité de nouveaux développements, les correctifs de bugs et les déploiements.

Pour commencer, nous implémentons des composants et des directives créés dans le projet front de Steeple et nous attendons plusieurs mois pour mettre en lumière les complexités dans un système comme celui-ci. Et voici les 2 problématiques remontées.

Problème 1 : La complexité de développement

Le premier problème remonté est la complexité à travailler avec une librairie dès lors que nous souhaitons modifier le comportement d’un composant. En effet, il faut apporter ses modifications, tester, créer une nouvelle version de la librairie et l’installer dans notre projet. Ces actions sont redondantes et il est nécessaire de ne pas avoir trop de modifications à la volée à faire.

Pour répondre à ce problème, nous avons mis en place un projet Vue classique dans le dossier de la librairie. Ce projet uniquement utilisé pour le test nous permet de tester nos développements dans un environnement Vue classique hors de tous contextes. En effet, tous les développements inclus dans la librairie ne doivent pas inclure le contexte d’un seul projet. Cela remettrait en question tout le principe de la librairie.

Le deuxième réponse et plutôt basique, c’est d’écrire de la documentation pour que chaque nouveau développeur puisse avoir toutes les clés en main lorsqu’il arrive sur le projet.

Problème 2 — Tester la librairie en conditions réelles

Pour tester la librairie en conditions réelle, ce n’est pas si simple. Avec notre projet Vue intégré, on peut facilement tester notre développement et Storybook et les tests nous permettent aussi une validation de nombreux points avant le déploiement d’une nouvelle version. Mais, nous pourrions avoir besoin de simuler en environnement isométrique à la production. Par exemple, dans une phase de debug ou pour faire une vérification sur les exports de la librairie.

La commande yarn link pourrait être un concurrent sérieux pour répondre à cette problématique. Cette commande permet de créer un lien symbolique de notre dossier steeplify dans les node_modules.

Le défaut de cette solution est que le paquet représenté par le lien symbolique n’est pas représentatif du vrai paquet installé depuis la commande yarn.

Avec la commande yarn link, on retrouve dans les node_modules une arborescence comme ci-dessous.

Dans le cas où on installe le paquet depuis un registry, seules les fichiers définis dans la configuration du paquet (sous la propriété files dans package.json) sont présents.

Et en possession de cette information, on pourrait être confronté à des problèmes de fichiers non présents une fois qu’ont créé une version “officielle” du paquet.

En vérité, ce problème est un faux problème si on maîtrise bien la construction des paquets.

Pour répondre à cette problématique, nous avons décidé encore une fois d’utiliser la documentation. Nous avons donc créé un petit tuto permettant de simuler un environnement de production avec yarn pack qui permet de créer un dossier compressé de la librairie avec les mêmes conditions qu’un téléchargement depuis un registry NPM. On retrouve dans ce cas un environnement totalement identique !

Le bilan

Finalement, après nos différentes recherches et nos tests, on se rend compte que notre solution est viable, mais qu’elle pose des problématiques qu’on ne peut pas négliger.

Problème 1 : Les compétences design

Le premier problème que nous avons soulevé relève plus de compétences transverses que d’une problématique technique.

L’implémentation d’une librairie qui reflète un design système doit être pourvu d’un … design system. En tant que développeurs front, nous avons forcement des appétences sur ces sujets mais ce n’est malgré tout pas notre métier. Et dans la logique d’accélération et de développement de l’entreprise, il nous semblait nécessaire de recruter une personne compétente sur les sujets de design.

Problème 2 : L’expérience développeur

En tant que développeur, nous avons besoin de travailler avec un environnement de développement agréable et pratique à utiliser. Cela inclus par exemple de pouvoir reproduire des environnement isoprod rapidement et d’avoir un espace de testing, développement qui fonctionne sans projet tiers.

Pour répondre à cette problématique, nous avons mis en place en environnement de test directement dans la librairie. Techniquement, c’est un projet Vue classique configuré pour importer tous les développements de la librairie.

Du côté de l’environnement de production, nous avons fait un travail intermédiaire de rédaction de process permettant de simuler la production. C’est une solution intermédiaire qui devra évoluer et être automatisé.

Le travail est encore long pour que notre solution réponde complètement à nos besoins mais nous sommes convaincu des bienfaits que pourra nous apporter la librairie dans le développement de l’écosystème Steeple.