Prod

.gitignore

@@ -24,4 +24,5 @@ dist-ssr
 *.sw?
 
 # OTHER
-.env
+.env
+*storybook.log

.storybook/main.ts

@@ -0,0 +1,17 @@
+import type { StorybookConfig } from '@storybook/react-vite';
+
+const config: StorybookConfig = {
+  stories: ['../src/**/*.mdx', '../src/**/*.stories.@(js|jsx|mjs|ts|tsx)'],
+  addons: [
+    '@storybook/addon-onboarding',
+    '@storybook/addon-essentials',
+    '@chromatic-com/storybook',
+    '@storybook/addon-interactions',
+    '@storybook/addon-themes'
+  ],
+  framework: {
+    name: '@storybook/react-vite',
+    options: {},
+  },
+};
+export default config;

.storybook/manager.ts

@@ -0,0 +1,6 @@
+import { addons } from '@storybook/manager-api';
+import theme from './theme';
+
+addons.setConfig({
+  theme,
+});

.storybook/preview.ts

@@ -0,0 +1,29 @@
+import type { Preview } from '@storybook/react';
+import { withThemeByClassName } from '@storybook/addon-themes';
+import theme from './theme';
+import '@/styles/index.css';
+
+const preview: Preview = {
+  parameters: {
+    backgrounds: {
+      values: [{ name: 'Dark', value: '#1B1919' }],
+      default: 'Dark',
+      docs: { theme },
+      controls: {
+        matchers: {
+          color: /(background|color)$/i,
+          date: /Date$/i,
+        },
+      },
+    },
+  },
+};
+
+export const decorators = [
+  withThemeByClassName({
+    themes: { dark: 'dark' },
+    defaultTheme: 'dark',
+  }),
+];
+
+export default preview;

.storybook/theme.ts

@@ -0,0 +1,11 @@
+import { create } from '@storybook/theming/create';
+
+export default create({
+  base: 'dark',
+  brandTitle: 'Castled Components Srtorybook',
+  brandUrl: 'https://castled.app',
+  brandImage: 'https://castled.app/logo.svg',
+  brandTarget: '_self',
+
+  appBg: '#1B1919',
+});

docs/CICD.md

@@ -0,0 +1,110 @@
+# Intégration Continue (CI) du Dépôt Front
+
+## Vue d'ensemble
+
+
+Le dépôt Front utilise GitHub Actions pour l'intégration continue, permettant d'automatiser les tests et les builds à chaque modification du code. Cette documentation détaille la configuration et le fonctionnement de la CI pour le dépôt Front.
+
+## Configuration de la CI
+
+### Fichier de configuration principal
+
+La CI est configurée dans le fichier `.github/workflows/build.yml`.
+
+## Déclencheurs
+
+La CI est déclenchée dans les cas suivants :
+
+1. **Push** sur les branches :
+
+   - `main` (production)
+
+   - `staging` (pré-production)
+
+   - `develop` (développement)
+
+   - Branches de correction (`fix/**`)
+
+   - Branches de correction urgente (`hotfix/**`)
+
+2. **Pull Requests** vers les branches :
+
+   - `main`
+
+   - `staging`
+
+   - `develop`
+
+   - Branches de correction (`fix/**`)
+
+   - Branches de correction urgente (`hotfix/**`)
+
+   - Branches de fonctionnalités (`feat/**`)
+
+## Étapes du workflow
+
+Le workflow de CI exécute les étapes suivantes :
+
+1. **Checkout du code** : Récupération du code source du dépôt
+
+2. **Mise en cache** : Configuration du cache pour les modules Node.js et le build Vite
+
+   - Optimise les performances en évitant de télécharger les dépendances à chaque exécution
+
+   - Utilise un système de clés basé sur le contenu des fichiers pour invalider le cache si nécessaire
+
+3. **Configuration de Node.js** : Installation de Node.js v20.x
+
+4. **Installation des dépendances** : Exécution de `npm ci` pour installer les dépendances exactes du projet
+
+5. **Build du projet** : Exécution de `npm run build` pour vérifier que le projet peut être compilé sans erreur
+
+6. **Tests** : Exécution des tests avec `npm test` (si présents)
+
+## Mirroring du dépôt
+
+En plus de la CI, le dépôt Front est configuré pour être synchronisé avec un dépôt privé via le workflow `.github/workflows/mirror.yml`.
+
+Ce workflow est déclenché pour tous les push et pull requests sur toutes les branches, et synchronise le dépôt avec un miroir privé.
+
+## Validation locale avant commit
+
+Le dépôt utilise également Husky pour exécuter des hooks Git localement avant les commits :
+
+```sh
+# .husky/pre-commit
+# On vérifie les fichiers modifiés avant et après l'exécution d
+MODIFIED_FILES_BEFORE=$(git diff --name-only)
+
+# On exécute le linter et le formateur de code
+# npm run lint -> temporarily removed
+npm run format
+```
+
+Ce hook pré-commit s'assure que le code est correctement formaté avant d'être commité, en utilisant les règles définies dans `.prettierrc`.
+
+## Intégration avec le workflow Gitflow
+
+## Environnement de développement
+
+Le projet utilise un fichier `.env` pour la configuration (basé sur `.env.example`), qui définit notamment l'URL de l'API :
+
+## Gestion des problèmes
+
+Le dépôt utilise des templates d'issues GitHub pour standardiser les rapports de bugs, demandes de fonctionnalités et autres tâches :
+
+- Bug reports
+
+- Feature requests
+
+- Chores
+
+- Refactoring
+
+- Improvements
+
+- Typo fixes
+
+- Style changes
+
+Ces templates facilitent le suivi des problèmes et leur intégration dans le workflow de développement.

docs/Gitflow.md

@@ -0,0 +1,71 @@
+# Gitflow
+
+## Branches Principales
+
+- **main** : Cette branche contient le code en production. Il doit toujours être stable et ne doit pas contenir de version non prête à être déployée.
+- **develop** : Cette branche sert à intégrer les fonctionnalités. Elle contient le code qui est prêt à être testé avant son intégration dans `main`.
+
+## Branches de Support
+
+- **feat/** : Utilisées pour le développement de nouvelles fonctionnalités. Chaque fonctionnalité a sa propre branche, par exemple `feat/ajout-authentification`.
+- **fix/** : Utilisées pour corriger des bugs non critiques identifiés en phase de développement. Chaque correction a sa propre branche, par exemple `fix/correction-bug-login`. Ces branches sont créées à partir de `develop` et fusionnées dans `develop` une fois la correction terminée.
+- **hotfix/** : Utilisées pour les corrections urgentes sur la branche `main`. Elles permettent de résoudre rapidement des problèmes critiques en production. Les branches `hotfix/` sont créées à partir de `main` et, une fois la correction apportée, sont fusionnées dans `main` et `develop` pour assurer la synchronisation des correctifs.
+
+- **release/** : Utilisées pour préparer une nouvelle version. Elles permettent de finaliser les tests et les corrections avant de fusionner dans `main`.
+
+## Workflow
+
+1. **Développement de Fonctionnalités** :
+   - Créez une branche `feat/` à partir de `develop`.
+   - Développez la fonctionnalité et testez-la.
+   - Fusionnez la branche `feat/` dans `develop` une fois terminée.
+
+2. **Correction de Bugs** :
+   - Créez une branche `fix/` à partir de `develop`.
+   - Corrigez le bug et testez la correction.
+   - Fusionnez la branche `fix/` dans `develop` une fois terminée.
+
+3. **Hotfix** :
+   - Créez une branche `hotfix/` à partir de `main`.
+   - Appliquez la correction urgente.
+   - Fusionnez la branche `hotfix/` dans `main` et `develop`.
+
+4. **Préparation d'une Version** :
+   - Créez une branche `release/` à partir de `develop`.
+   - Finalisez les tests et les corrections.
+   - Fusionnez la branche `release/` dans `main` et `develop`.
+
+## Utilisation d'Outils pour Simplifier le Workflow
+
+Pour faciliter l'adoption et l'application cohérente du Gitflow, il est recommandé d'utiliser des outils dédiés :
+
+- **Extensions Gitflow** : Des extensions comme `git-flow` automatisent la création et la gestion des branches selon les conventions Gitflow. Elles ajoutent des commandes simplifiées pour initier des fonctionnalités, des releases ou des hotfixes.
+
+**Installation de `git-flow`** :
+- **macOS** : `brew install git-flow`
+- **Windows** : Inclus dans certaines distributions Git pour Windows ou disponible via des installateurs tiers.
+- **Ubuntu/Debian** : `apt-get install git-flow`
+
+**Initialisation du dépôt avec `git-flow`**:
+Après installation, initialisez `git-flow` dans votre dépôt :
+
+```bash
+git flow init
+```
+
+Cette commande configure les branches par défaut (`main` et `develop`) et définit les préfixes pour les branches de support (`feat/`, `release/`, `hotfix/`).
+
+## Bonnes Pratiques
+
+- Assurez-vous que le code est bien testé avant de fusionner dans `develop` ou `main`.
+- Utilisez des **pull requests** pour faciliter la revue de code.
+- Gardez les branches `main` et `develop` à jour avec les dernières modifications.
+- Utilisez des messages de commit explicites et conformes aux conventions de votre équipe.
+- Mettez en place des pipelines d'intégration continue pour automatiser les tests et les déploiements.
+
+- **Convention de Nommage des Branches**:
+    Adoptez une convention claire pour le nommage des branches, par exemple :
+    - Fonctionnalités : `feat/nom-fonctionnalité`
+    - Corrections : `fix/description-correction`
+    - Releases : `release/x.y.z` (où `x.y.z` représente le numéro de version)
+    - Hotfixes : `hotfix/description-correction`