hello, je vous propose de mettre du husky qui reformate tout le code modifié au moment de faire un commit,
comme ça on a une harmonie basée sur eslint automatiquement.
j’ai fait une MR pour ajouter ça sur le duniter
typescript.
mais vous pouvez le mettre aussi dans les autres projets, comme ça plus de soucis de relecture uniquement lié au formattage de code
Merci @tykayn pour la proposition, mais la commitologie ne me conviens pas. Ce serait bien d’avoir un seul commit pour l’ajout du formatter puis un seul commit pour tout formater (ce que tu a fait pour ce 2 ème cas).
Aussi, je veut bien savoir quel est la commande permettant de tout formater ?
Par contre, je vois que tu formate aussi les fichiers .js, ce qui ne sert a rien car tout le code source est en .ts uniquement, les fichiers .js sont générés automatiquement on ne les modifie jamais a la main, d’ailleurs ils sont dans le .gitignore 
Et attention tu a ajouté la dépendance duniter-ui ce qu’il ne faut pas faire car duniter est indépendant de l’interface graphique d’administration, on doit pouvoir installer duniter sans celle-ci (et donc administrer duniter en ligne de commande).
Enfin, vu que j’apporte beaucoup de changement avec la branche feature/oxyde-crypto j’aimerai la merger d’abord avant d’ajouter le formatteur (car sinon il vas y avoir des conflits ingérables). Si tu veut je peut le refaire en me basant sur ton code, il me faut juste la commande pour tout formater 
Merci
husky va lancer des git hooks qui sont décrits dans le package.json, section husky.
la commande pré-commit fait un coup de lint sur les fichiers en état de staging dans git, qui lui fait un coup de « prettier »
prettier --write --cache app/**/*/*.ts
pour ajouter cela à son projet il faut faire du npm execute
npx mrm lint-staged
je vais modifier les commits pour n’avoir plus que l’install du husky et le reformattage complet sur la merge request
et voilà
@tykayn suite a ta motivation pour contribuer je me suis motivé a définir des conventions git explicites pour le dépôt Duniter, elles ne sont bien entendu pas figées dans le marbre a jamais, on pourra les modifier si nécessaire, mais au moins ont à une base pour partir sur quelque chose
Concernant ta MR je l’ai refaite en respectant les conventions git désormais définies, et surtout en étant plus rigoureux sur les commits, tu avais encore de reformatage dans le 1er commit
Aussi, j’ai modifié les commandes pour que seuls les fichiers .ts soient formatées, car se sont les seuls a être versionnées par git.
Enfin, je me pose la question de la pertinence de versionner le fichier .escache, ne serait t"il pas pertinent de le placer dans le .gitignore ?
Merci encore @tykayn pour ton initiative, j’espère que tu n’es pas trop frustré que je l’ai finalisée moi-même pour que ce soit dans les clous, mais c’était aussi pour t’éviter d’avoir a tout refaire suite au merge de la feature oxyde-crypto
ah ok, je me demandais où c’était passé X)
pas de soucis, du moment que ça roule bien!