Retrouvez ici toutes nos règles de travail du code !
Ce code de conduite a pour but de vous aider à comprendre comment nous travaillons et comment vous pouvez nous aider à améliorer le projet. Il est important de le lire et de le comprendre avant de contribuer au projet.
Ce code de conduite a été créé pour définir les règles de travail du code. Il est important de le lire et de le comprendre avant de contribuer au projet.
La structure du projet est généralement lié au langage et au framework utilisé. Il est important de respecter cette structure pour que le projet soit facilement compréhensible par tous les développeurs. La structure proposé par le framework lui même est la plus approprié car la documentation du framework lui même sert de base pour nos projets.
Les variables d'environnement sont importantes pour que le code soit facilement compréhensible par tous les développeurs. Il est important d'utiliser les variables d'environnement pour que le code soit facilement compréhensible par tous les développeurs.
Toutes les dépendances au code ainsi que le code lui même doivent se trouver dans le dossier /data du conteneur ou de la machine virtuelle.
Le nommage est important pour que le code soit facilement compréhensible par tous les développeurs. Il est important de respecter les règles de nommage pour que le code soit facilement compréhensible par tous les développeurs.
Voir styleguide
!!! ATTENTION !!! Le type de TypeScript any est un super et un sous-type de tous les autres types et permet de déréférencer toutes les propriétés. En tant que tel, any c'est dangereux - il peut masquer de graves erreurs de programmation et son utilisation mine l'intérêt d'avoir des types statiques en premier lieu.
Les tests sont importants pour que le code soit facilement compréhensible par tous les développeurs. Il est important de réaliser des tests pour que le code soit facilement compréhensible par tous les développeurs.
- Générer automatiquement des CHANGELOGs.
- Déterminer automatiquement un changement de version sémantique (en fonction des types de commits inclus).
- Communiquer la nature des changements aux membres de l’équipe, au public et aux autres parties prenantes.
- Déclencher des processus de génération et de publication.
- Faciliter la contribution des personnes à vos projets en leur permettant d’explorer un historique de commit plus structuré.
Le commit contient les éléments structurels suivants, permettant de communiquer à l’intention des consommateurs de votre API :
- fix un commit de type fix corrige un bogue dans le code (cela est en corrélation avec PATCH en gestion sémantique de versions).
- feat: un commit de type feat introduit une nouvelle fonctionnalité dans le code (cela est en corrélation avec MINOR en gestion sémantique de versions).
- BREAKING CHANGE: un commit qui contient dans son pied le mot-clé BREAKING CHANGE:, ou dont le type/étendue est suffixé d’un !, introduit une rupture de compatibilité dans l’API (cela est en corrélation avec MAJOR en gestion sémantique de versions). Un BREAKING CHANGE peut faire partie des commits de n’importe quel type.
- Les types autre que fix: et feat: sont autorisés; par exemple, @commitlint/config-conventional (basé sur the Angular convention) recommande build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, etc.
- Les pieds autres que BREAKING CHANGE: peuvent être fournis et suivre une convention similaire à git trailer format.
- Les types supplémentaires ne sont pas prescrits par la spécification de Commits Conventionnels et n’ont aucun effet implicite dans la gestion des versions sémantiques (à moins qu’ils ne comportent un BREAKING CHANGE). Une étendue peut être fournie au type d’un commit pour fournir des informations contextuelles supplémentaires. Elle est indiquée entre parenthèses, par exemple, feat(parser): add the ability to parse arrays.
Voir conventionalcommits.
Étant donné un numéro de version MAJEUR.MINEUR.PATCH, il faut incrémenter :
le numéro de version MAJEUR quand il y a des changements non rétrocompatibles, le numéro de version MINEUR quand il y a des ajouts de fonctionnalités rétrocompatibles, le numéro de version de PATCH quand il y a des corrections d’anomalies rétrocompatibles. Des libellés supplémentaires peuvent être ajoutés pour les versions de pré-livraison et pour des méta-données de construction sous forme d’extension du format MAJEURE.MINEURE.PATCH.
Voir semver.
