Sur ce projet, yarn
est le gestionnaire de paquets utilisé
Avoir la version LTS de Node décrite dans le fichier .nvmrc
.
nvm install v20.x.x
D'abord, installer les dépendances
yarn install
Remplir les variables d'environnement dans .env.local
.
Lancer le serveur de développement
yarn db:start
yarn dev
Ouvrir le navigateur sur http://localhost:3000 pour voir le résultat
Pour lancer les tests une fois :
yarn test
Pour lancer les tests en continu :
yarn test:watch
Pour lancer les tests avec le coverage :
yarn test:coverage
Pour accéder à la base de données en CLI selon un environnement :
yarn psql:local
yarn psql:production (il faut avoir installer la CLI de Scalingo au préalable)
yarn psql:test
Pour accéder à la base de données de production avec un outils, il faut lancer un tunnel SSH avant :
scalingo -a suite-gestionnaire-numerique db-tunnel -i [CHEMIN_DE_TA_CLE_SSH_SCALINGO] [VAR_ENV_SCALINGO_POSTGRESQL_URL]
Ensuite, dans ton outils, tu configures avec 127.0.0.1:10000 et le reste grâce à la variable d'environnement SCALINGO_POSTGRESQL_URL utilisée juste au dessus.
Quand le schéma de SGN est modifié, regénérer les tables à partir des schémas Prisma, créer les migrations au besoin et générer les types pour Prisma Client :
yarn prisma:migrate
Quand tu veux ré-initialiser la base de données :
yarn prisma:drop:schema
Quand le schéma de FNE est modifié, regénérer les types FNE pour Prisma Client :
yarn prisma:generate:fne
Quand tu veux enchainer les trois dernières commandes d'affilé :
yarn prisma:reset
Quand tu veux importer les utilisateurs :
yarn migration:utilisateur
Ne pas oublier de copier/coller le fichier JS et les pictos dans /public
.
- Permet d'avoir du typing pour minimiser l'écriture de bug
- Permet d'avoir un feedback rapide d'erreur
- Permet d'avoir la notion d'interface pour étendre des classes
- Configurer tout en strict pour avoir une haute qualité de développement
- Permet de formatter le JavaScript
- Permet de réduire l'écriture de bug
- Permet d'avoir un feedback rapide d'erreur
- Configurer en strict pour avoir une haute qualité de développement
- Ajout de quelques plugins pour renforcer
- Permet de réduire l'écriture de bug
- Permet d'avoir un feedback rapide d'erreur
- Configurer en strict pour avoir une haute qualité de développement
- Ajout de quelques plugins pour renforcer
- Permet de formatter le CSS, JSON et markdown
- Permet de détecter les modules inutilisés pour l'application et par conséquent réduire son déploiement
- Permet de détecter le code mort et par conséquent réduire la charge cognitive
- Permet de lancer la CI en local au pre-push plutôt que sur GitHub pour :
- Avoir un feedback plus rapide
- Consommer moins d'énergie car on ne retélécharge pas tout les node_modules
- Gagner du temps
- Le meilleur framework de test actuellement dans l'éco-système JavaScript
- La configuration respecte F.I.R.S.T. pour une meilleure robustesse
- Le coverage est configuré pour mettre en valeur si c'est en dessous de 90 %
- Le meilleur framework de test actuellement pour le frontend dans l'éco-système JavaScript
- Permet de lancer des tests de mutation
- Renforce la robutesse des tests
📦 Suite gestionnaire numérique
┣ 📂 .github/workflows -> Configuration de CodeQL et dependabot
┣ 📂 .husky/workflows -> Configuration du pre-push
┣ 📂 public -> Assets statiques dont le dsfr.js
┣ 📂 src
┃ ┣ 📂 app -> Les controllers
┃ ┣ 📂 components
┃ ┃ ┣ 📂 [UnComposant] -> Un composant de type page et ses enfants qui en découlent
┃ ┃ ┣ 📂 shared -> Les composants partagés par toute l'application (ExternalLink...)
┃ ┃ ┗ 📂 transverse -> Les composants transverses à toute l'application (EnTete, PiedDePage...)
┃ ┣ 📂 domain -> Les objets métier
┃ ┣ 📂 gateways -> Les repositories, loaders et gateways
┃ ┣ 📂 presenters -> Les presenters
┃ ┗ 📂 use-cases -> Les use cases, queries et commands
┣ 📜 .editorconfig -> Configuration de règles de formattage de base
┣ 📜 .env -> Valeurs par défaut des variables d'environnement
┣ 📜 .env.local -> Variables d'environnement locale
┣ 📜 .eslintrc -> Configuration ESLint
┣ 📜 .gitignore -> Fichiers à ne pas commiter
┣ 📜 .nvmrc -> La version de Node à utiliser
┣ 📜 .prettierrc -> Configuration Prettier
┣ 📜 .slugignore -> Les fichiers ignorés de l'image Scalingo au build (étant limité à 1,5 Go)
┣ 📜 .stylelintrc -> Configuration Stylelint
┣ 📜 knip.json -> Configuration Knip
┣ 📜 next.config.js -> Configuration de Next
┣ 📜 package.json -> Configuration du projet Node
┣ 📜 scalingo.json -> Configuration de Scalingo
┣ 📜 sentry.xxx.config.ts -> Configuration de Sentry
┣ 📜 stryker-backend.conf.json -> Configuration de Stryker
┣ 📜 stryker-frontend.conf.json -> Configuration de Stryker
┣ 📜 tsconfig.json -> Configuration de TypeScript
┣ 📜 vitest.config.js -> Configuration de Vitest
┣ 📜 vitest.setup.js -> Actions à exécuter avant tous les tests
- Définition : la porte d'entrée d'un utilisateur : une page au sens Next ou une route API et font office d'orchestrateur pour séparer les responsabilités
- Convention : PascalCase (fonction), avec comme suffixe
Controller
(ex :AccueilController
) - Test : à définir
- Définition : un composant TSX
- Convention : PascalCase (classe) et aucune logique dedans (ex :
MesInformationsPersonnelles
), elle est dans un hook custom à côté pour séparer les responsabilités - Test : test de sémantique et d'actions utilisateur
- Définition : c'est le métier, agnostisque de l'infrastructure
- Convention : PascalCase (classe) (ex :
Utilisateur
) - Test : test unitaire classique
- Définition : manipulation de données
- Loader : lecture de données qui retourne un
Record
et qui le transforme enReadModel
(ex :InMemoryMesInformationsPersonnellesLoader
) - Repository : écriture de données qui ne retourne rien
- Gateway : lecture et écriture de données qui retourne autre chose que du métier (
DTO
) (ex :ProConnectAuthentificationGateway
)
- Loader : lecture de données qui retourne un
- Convention : PascalCase (classe), avec comme préfixe son implémentation et comme suffixe son type de gateway
- Test : test d'intégration qui commnunique avec la base de données mais en transcation rollbackée pour être plus rapide
- Définition : transforme un
ReadModel
en unViewModel
de manière à ce qu'un composant puisse l'afficher - Convention : camelCase (fonction) (ex :
mesInformationsPersonnellesPresenter
) - Test : à définir
- Définition :
- use case : à définir
- interface : interface que doit implémenter une gateway (ex :
UnUtilisateurLoader
) - read model : read model (type) que doit utiliser une gateway (ex :
UtilisateurReadModel
) - erreur : PascalCase (classe), erreur métier (ex :
UtilisateurNonTrouveError
)
- Convention : PascalCase (classe)
- Test : à définir