API NestJS minimaliste — support du TP cours-02.
Ce dépôt est divisé en deux parties pédagogiques distinctes :
| Répertoire | Contenu |
|---|---|
docker-practice/ |
Partie 1 — Docker : exercice indépendant sur les commandes de base |
src/, prisma/, etc. |
Partie 2 — GitHub Flow : API NestJS à faire évoluer |
Prérequis : VS Code + Docker Desktop + extension Dev Containers
-
Forker le dépôt, puis cloner votre fork :
git clone <url-du-fork> cd cours-02-github-flow-api
-
Ouvrir le dossier dans VS Code et accepter "Reopen in Container" — ou utiliser la palette de commandes :
Dev Containers: Reopen in Container. -
Attendre l'initialisation. La première ouverture peut prendre environ deux minutes.
-
Exécuter les commandes du TP dans le terminal du DevContainer.
Le DevContainer est le mode attendu pour ce TP. Le démarrage manuel n'est utile qu'en dépannage.
Prérequis : Node.js 24, PostgreSQL 18
-
Copier et renseigner les variables d'environnement :
cp .env.example .env # Éditer .env : renseigner DATABASE_URL -
Installer les dépendances :
npm install
-
Appliquer les migrations :
npx prisma migrate dev --name init
-
Lancer l'application :
npm run start:dev
Voir
docker-practice/README.mdpour les instructions complètes.
Cette partie se fait dans le DevContainer, sur une branche dédiée :
git checkout main
git pull
git checkout -b feature/docker-practiceTu vas écrire un Dockerfile minimaliste, construire une image, lancer un conteneur, puis faire le nettoyage.
Implémenter la fonctionnalité manquante GET /tasks?done=true et GET /tasks?done=false en suivant le GitHub Flow.
Le query param done est obligatoire pour cet exercice. C'est un booléen transmis sous forme de chaîne dans l'URL :
done=trueretourne uniquement les tâches terminées ;done=falseretourne uniquement les tâches non terminées.
- Revenir sur
mainet récupérer la dernière version. - Créer une branche
feature/add-task-filterdepuismain. - Implémenter le filtrage booléen dans
TasksServiceetTasksController. - Adapter les tests existants.
- Vérifier que les tests passent avec
npm test. - Committer avec un message Conventional Commits.
- Pousser la branche et ouvrir une Pull Request.
- Traiter les retours de relecture.
- Fusionner la Pull Request dans
main. - Vérifier que
mainreste fonctionnelle après la fusion. - Préparer le passage en
1.0.0surmain:- mettre à jour
package.jsonetpackage-lock.jsonde0.0.1vers1.0.0; - créer ou mettre à jour
CHANGELOG.mdavec les changements livrés ; - committer ces fichiers avec le message
chore(release): bump project to version to 1.0.0.
- mettre à jour
- Depuis l'interface web GitHub, créer une release manuelle en renseignant le tag
v1.0.0basé sur ce commit de release, avec un titre et des notes de version. GitHub créera le tag au moment de publier la release.
Par défaut, la Pull Request est ouverte dans ton fork : la branche feature/add-task-filter est proposée vers main de ton dépôt forké.
Si l'enseignant le demande explicitement, la Pull Request peut être ouverte vers le dépôt central GVI2026/tp-github-flow. Sans droit d'écriture ou sans accès GitHub disponible, le même raisonnement peut être simulé localement en comparant la branche de feature avec main, puis en expliquant le merge attendu.
| Méthode | Route | Description |
|---|---|---|
POST |
/tasks |
Créer une tâche |
GET |
/tasks |
Lister toutes les tâches |
GET |
/tasks/:id |
Récupérer une tâche |
PATCH |
/tasks/:id |
Mettre à jour une tâche |
DELETE |
/tasks/:id |
Supprimer une tâche |
GET |
/tasks?done=true |
|
GET |
/tasks?done=false |
Swagger est disponible sur http://localhost:3000/api après lancement de l'application :
npm run start:devnpm testUne fois la Partie 2 terminée, tu peux implémenter la pagination sur GET /tasks via les query params ?page= et ?limit=.
Exemple : GET /tasks?page=1&limit=10
Même démarche : nouvelle branche feature/add-pagination, Pull Request, merge, puis release manuelle si l'enseignant le demande.