Refacto règles

[johangirod]

Nettoyage des règles publicodes avant publication de l'API

• Renommage contrat salarié en salarié
• Ajout d'un espace 'contrat' ou toutes les informations contractuelles ont été déplacées (brut de base, temps de travail, type de contrat)
• Utilisation tant que possible de avec
• Déplacement des éléments de rémunération dans l'espace de nom "rémunération"
• Déplacement des exonérations dans 'salarié . cotisations . exonérations'

Fix #2114

[fmata]

Ouch, c'est un sacré changement cassant :fearful:

Un fichier UPGRADE.md serait très apprécié ainsi qu'une date approximative de publication sur NPM car ça va nous demander pas mal de temps à mettre à jour dans nos règles personnalisées + le risque de régressions... merci d'avance.

[johangirod]

Effectivement, c'est un changement très cassant. L'idée est de nettoyer enfin toutes ces règles afin de pouvoir être serein sur leur maintien dans le futur et de ne plus avoir de changement cassant lors des prochaines mise à jour.

Nous publierons un fichier contenant la liste de tous les renommages de variables (quand c'est possible), et nous passerons en version 1.0.0.

Par ailleurs, nous réfléchissons à une manière de spécifier des espaces de nom non stable ou non maintenus, susceptibles de recevoir des changements cassant dans le futur (par exemple, les convention collectives). Cela pourrait être fait via un tag 'beta'.

Concernant le risque de régressions côté mon-entreprise, il est très limité dû aux nombreux tests de non-régression présents (ils sont dans le dossier /site).

En revanche, il y aura sans doute un peu de travail pour modifier les règles custom, mais ce sera la dernière fois qu'un changement cassant de cette ampleur arrivera, ce qui facilitera les mises à jour prochaines. Par ailleurs, vous n'êtes pas obligé d'actualiser le package immédiatement.

Concernant la date, ce sera sans doute pour la deuxième quinzaine de juin.

[fmata]

Je comprends bien l'idée de ces changements et je vais dans ton sens.

Mon message avait surtout pour but d'avoir de la visibilité sur les développements futurs et pour planifier les mises à jour de notre côté car oui, cela va entraîner de nombreuses modifications dans notre code et nos règles. Heureusement nous avons aussi une (grosse) suite de tests mais par définition elle n'est pas incluse à la vôtre et donc peut être que nous découvrirons des surprises.

A propos des règles ou espaces de nom "beta", je vous suggère d'introduire une notion de compatibilité :

ma règle: 2000 €/mois
  expérimental:
    depuis: 1.0.1

mon autre règle: 2000 €/mois
   déprécié:
      depuis: 1.0.1
      sera supprimé: 2.0.0
      message: La règle "ma nouvelle règle" doit être utilisée à la place.

"expérimental" signifie que la règle n'est pas couverte par une promesse de non cassure de la compatibilité vers une version supérieure (BC promise), à utiliser à nos risques et périls.

Cela veut dire aussi qu'il faudrait d'abord passer par une phase de dépréciation avant de supprimer/renommer/remplacer une règle. Avec ça on a facilement la liste des règles dépréciées qui sont utilisées (un peu comme les warning actuellement), en plus de clarifier la base de règles en elle-même.

Qu'en penses-tu ?

[github-actions[bot]]

🚀 La branche est déployée !

• mon-entreprise : https://2143--mon-entreprise.netlify.app
• mycompanyinfrance : https://2143-en--mon-entreprise.netlify.app
• storybook : https://2143--mon-entreprise.netlify.app/dev/storybook/ (version EN)
• API : https://2143--mon-entreprise.netlify.app/api/v1/doc/