[RFC]: publier une config jest
pierrezimmermannbam opened this issue · 3 comments
Je voudrais récolter vos opinions sur la pertinence de rajouter sur ce repo des configs jest et rntl et de les publier sur npm.
Concrètement, on aurait une config expo et une config bare RN exportée et on les utiliserait comme ça
const baseConfig = require('@bam.tech/jest-config-expo');
module.exports = {
...baseConfig,
// overrides
};Avantages
Partage des best practices
On partage beaucoup de choses dans les config de jest sur les différents projets. Actuellement on fait des copier coller depuis la bootstrap doc ou alors depuis d’anciens projets (le pire cas potentiellement parce que les configs sont pas forcément bonnes)
En plus de rendre la maintenance plus compliquée, on peut passer à côté de choses très sympas qu’on a implémentées sur les enablers comme sucrase, le clear des mocks, le matcher custom pour les snapshots pour n'en nommer que quelques uns.
Setup et facilité de maintenance
Les projets auraient juste à installer le package et si tout va bien ça devrait rouler. Ensuite s'il y a des nouveautés ils auraient juste à bump le package
Open sourcé
Un autre avantage c’est que ça pourrait être open sourcé, je sais pas trop si ça serait utilisé en dehors de bam mais ça mange pas de pain
Maintenance des enablers
C'est peut-être un des points les plus importants. Aujourd'hui on a une config jest au niveau de chaque module (joconde, doc, cli, warehouse) et c'est un copié collé, du coup si on fait une modif à un endroit il faut la faire partout. Si on avait un package on aurait une seule source de vérité. Cependant on pourrait aussi résoudre ce problème de manière différente, par exemple en mettant la config à la racine et en référençant cette config dans la doc (ce qui serait sans doute une bonne idée, même si on avait le package publié on aurait pas à bump la version partout)
Inconvénients
Malheureusement tout n'est pas rose quand on utilise une lib pour sa config jest (j'en ai fait l'expérience sur un ancien projet):
- la config est cachée en grande partie, i.e. on doit aller voir dans les node_modules pour voir ce qui se cache dans la config, pas très commode pour debug
- niveau formation c’est pas optimal non plus, ça devient une boite noire et on court le risque que la connaissance de ces configs disparaisse
- est-ce que c’est vraiment plus commode que la bootstrap doc ou que la config de la joconde ? Faire un copier coller ça va vite et on peut choper ce qu’on veut derrière. Ici il faudrait savoir si la config dans les enablers est consultée fréquemment aujourd'hui et si c'est pas le cas est-ce qu'avoir un package publié la rendrait plus populaire.
- La config a beaucoup bougé au début des enablers mais dans le futur est-ce que ça a vocation a beaucoup évoluer ? Pas sûr du tout, auquel cas un brave cp depuis les enablers ferait le taf
Ces inconvénients sont modérés par le fait qu’on pourrait toujours cp le code du package publié pour garder les avantages qu’on avait avant en terme de flexibilité et de lisibilité (même si on pourrait galérer pendant des mois avant de prendre l'action de faire un cp plutôt qu'utiliser la lib)
Je ne suis pas moi-même convaincu que ça soit une bonne idée mais je ne suis pas non plus convaincu que ça soit une mauvaise idée donc chaud pour vos retours
Est-ce qu'on peut imaginer quelque chose plus dans l'esprit de warehouse où on téléchargerait la dernière version de la config, git diff et merge (avec résolution de conflits potentiels) ? Tout ça automatisé dans une commande de CLI. Je pense à la "lib" shadcn/ui qui a une approche copier-coller plutôt que package npm : https://ui.shadcn.com/docs/changelog#diff-experimental. Si toute la config est bien documentée ligne par ligne, tu peux ensuite choisir de garder les lignes qui t'intéressent pas.
Sur les enablers, si tous les packages utilisent la même config, on pourrait lancer cette commande sur tous les packages dès qu'on fait une modif de la config jest (même directement dans la CI ?)
Sinon un compromis ça serait de télécharger la config telle quelle dans un fichier jest.bam.config.js et de l'override dans jest.config.js. En gros, comme ce que tu proposes mais dans un fichier du repo plutôt que dans node_modules
Hmm c'est une approche intéressante en effet. Le problème c'est que pour le moment la CLI est pas très développée, il y a pas mal de taf à faire dessus.
Comment ça fonctionne la diff exactement ? De ce que je vois il y a quand même un package npm donc est-ce que la commande de diff fait pas juste pour toi le taf de regarder les changelogs des nouvelles versions ? Si on a un fichier en local qu'on a un peu custom on aura toujours des diffs avec l'upstream non ? Si tu la gardes dans un fichier à part ça résout le problème mais ça peut être assez incompréhensible qu'il faut maintenir l'original dans son repo
Aussi le désavantage c'est que t'auras pas des majs automatiques que tu pourrais avoir si t'as un bot pour gérer les deps par exemple.
J'aime bien l'idée de partager la config en lib car on peut avoir pas mal de chose dedans :
- les snapshots customs
- la config jest
- les matchers jest que Pierre a créé toHaveBeenCalledOnceWith, et toHaveBeenCalledNTimesWith