feat(auth,events): documentation OpenAPI generee, client frontend Orval - #68
Conversation
Le README annoncait des routes Swagger jamais implementees. Corrige en implementant reellement le contrat, pas seulement le README. - auth-service, event-service : swagger-jsdoc genere le contrat OpenAPI 3.0.3 depuis des annotations JSDoc @openapi au-dessus de chaque route (jamais de spec ecrite a la main). Servi en direct sur /api/<service>/docs (Swagger UI) et /api/<service>/docs.json (JSON brut). Verifie en conditions reelles via docker compose (dev) : les deux endpoints repondent a travers la vraie passerelle. - npm run docs:generate dans chaque service ecrit openapi.json (gitignore, regenerable, jamais committe). - frontend : Orval (choisi plutot qu'openapi-typescript, qui ne genere que des types et laisse ecrire chaque appel a la main ; Orval genere des fonctions Axios typees pretes a l'emploi) lit les deux openapi.json et genere un client dans src/api/generated/ (gitignore, jamais committe). npm run generate:api pour le regenerer. - Verifie de bout en bout, pas seulement compile : bundle du client genere execute reellement contre un auth-service en cours d'execution (base ephemere), inscription puis connexion reussies via les fonctions generees. - ADR 0011 : justifie le choix, documente le workflow en 3 commandes, precise que les .ts generes n'impliquent pas de migration TypeScript (Vite les transpile sans verification de types). - AGENTS.md : regle explicite, contrat et client toujours generes, jamais ecrits a la main. - participants-service, registrations-service : README mis a jour pour suivre le meme patron des qu'ils auront du code reel.
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
📝 WalkthroughWalkthroughChangesOpenAPI and Orval API generation
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant AuthService
participant EventService
participant Orval
participant AxiosInstance
AuthService->>Orval: Provide auth OpenAPI specification
EventService->>Orval: Provide events OpenAPI specification
Orval->>AxiosInstance: Use customInstance for generated clients
Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
Cette PR met en place une documentation OpenAPI réellement servie par les services auth-service et event-service à partir d’annotations @openapi dans le code, et ajoute le workflow de génération du client frontend via Orval, conformément aux règles ajoutées dans AGENTS.md et formalisées par l’ADR 0011.
Changes:
- Ajout de Swagger UI + endpoint
/docs.jsonsurauth-serviceetevent-service, avec génération OpenAPI viaswagger-jsdoc. - Ajout des scripts
docs:generate(écriture d’unopenapi.jsongitignoré) dans les deux services. - Ajout d’Orval côté frontend (
orval.config.js, scriptgenerate:api, mutator Axios) + documentation (ADR + READMEs) et.gitignorepour les artefacts générés.
Reviewed changes
Copilot reviewed 17 out of 21 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| registrations-service/README.md | Met à jour la checklist pour inclure Swagger/OpenAPI + génération. |
| participants-service/README.md | Met à jour la checklist pour inclure Swagger/OpenAPI + génération. |
| knowledge-base/adr/0011-openapi-genere-orval.md | Ajoute l’ADR décrivant la génération OpenAPI + client Orval. |
| frontend/src/api/axios-instance.js | Ajoute le mutator Axios utilisé par Orval (retourne response.data). |
| frontend/package.json | Ajoute le script generate:api et la devDependency orval. |
| frontend/package-lock.json | Lockfile mis à jour suite à l’ajout d’Orval. |
| frontend/orval.config.js | Configure Orval pour auth et events avec mutator Axios. |
| event-service/src/routes/events.js | Ajoute annotations @openapi sur GET/POST / et schémas partagés. |
| event-service/src/config/swagger.js | Ajoute la config swagger-jsdoc pour compiler les annotations. |
| event-service/src/app.js | Expose /api/events/docs (UI) et /api/events/docs.json (JSON). |
| event-service/scripts/generate-openapi.js | Ajoute le script qui écrit openapi.json depuis swaggerSpec. |
| event-service/package.json | Ajoute docs:generate + dépendances Swagger. |
| event-service/package-lock.json | Lockfile mis à jour suite aux dépendances Swagger. |
| auth-service/src/routes/auth.routes.js | Ajoute annotations @openapi sur /register, /login, /me + schémas. |
| auth-service/src/config/swagger.js | Ajoute la config swagger-jsdoc pour compiler les annotations. |
| auth-service/src/app.js | Expose /api/auth/docs (UI) et /api/auth/docs.json (JSON). |
| auth-service/scripts/generate-openapi.js | Ajoute le script qui écrit openapi.json depuis swaggerSpec. |
| auth-service/package.json | Ajoute docs:generate + dépendances Swagger. |
| auth-service/package-lock.json | Lockfile mis à jour suite aux dépendances Swagger. |
| AGENTS.md | Documente officiellement la règle OpenAPI généré + client Orval généré. |
| .gitignore | Ignore openapi.json et frontend/src/api/generated/ (artefacts générés). |
Files not reviewed (3)
- auth-service/package-lock.json: Generated file
- event-service/package-lock.json: Generated file
- frontend/package-lock.json: Generated file
Suppressed comments (1)
auth-service/src/routes/auth.routes.js:122
- La spec OpenAPI de POST /login ne documente pas la reponse 500, alors qu'une erreur interne est possible (respondError renvoie 500 avec un corps { error }). Pour un client genere (Orval), il vaut mieux declarer explicitement ce cas.
* 401:
* description: Identifiants incorrects (email inconnu ou mot de passe faux, meme message generique)
* content:
* application/json:
* schema:
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
🧹 Nitpick comments (3)
event-service/src/routes/events.js (1)
63-74: 🗄️ Data Integrity & Integration | 🔵 Trivial | ⚡ Quick winDocumenter les bornes de pagination.
Le gestionnaire ramène
pageetlimità une valeur minimale de1, mais les schémas n’indiquent aucunminimum. Ajouterminimum: 1aux deux paramètres afin que les clients générés et les validateurs utilisent le même contrat.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@event-service/src/routes/events.js` around lines 63 - 74, Update the pagination parameter schemas in the events route documentation to add minimum: 1 for both page and limit, matching the handler’s lower-bound behavior while preserving their existing defaults and limit maximum.auth-service/src/routes/auth.routes.js (1)
7-40: 🗄️ Data Integrity & Integration | 🔵 Trivial | ⚡ Quick winCompléter les schémas de réponse générés par Orval.
Les schémas n’expriment pas complètement les champs renvoyés par les services. Les propriétés sans
requireddeviennent optionnelles, et/me.userreste un objet non typé.
auth-service/src/routes/auth.routes.js#L7-L40: ajouter les champsrequireddeUser,AuthResponseetError.auth-service/src/routes/auth.routes.js#L148-L154: référencerUsersi les claims JWT correspondent, sinon créerTokenClaims.event-service/src/routes/events.js#L9-L54: ajouter les champsrequireddeEvent,PaginationetError.As per coding guidelines, le client frontend doit être généré par Orval à partir d’un contrat OpenAPI précis.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@auth-service/src/routes/auth.routes.js` around lines 7 - 40, Compléter les schémas OpenAPI en ajoutant les champs required attendus pour User, AuthResponse et Error dans auth-service/src/routes/auth.routes.js:7-40, pour Event, Pagination et Error dans event-service/src/routes/events.js:9-54, puis typer la réponse ou le schéma des claims JWT dans auth-service/src/routes/auth.routes.js:148-154 en référençant User lorsque les claims correspondent, sinon en créant TokenClaims.Source: Coding guidelines
frontend/orval.config.js (1)
4-15: 🗄️ Data Integrity & Integration | 🔵 Trivial | ⚡ Quick winActivez
cleandans les deux sorties Orval.Avec
mode: "tags-split", chaque route/tag peut produire un fichier dédié dansfrontend/src/api/generated/authoufrontend/src/api/generated/events. Sansclean: true, un fichier peut rester quand son tag ou son route correspondante disparaît, puis causer des imports morts ou des conflits de génération.Correction proposée
output: { mode: "tags-split", target: "./src/api/generated/auth", + clean: true, client: "axios", ... output: { mode: "tags-split", target: "./src/api/generated/events", + clean: true, client: "axios",🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@frontend/orval.config.js` around lines 4 - 15, Activer l’option clean: true dans les deux configurations de sortie Orval, les sorties auth et events, en conservant leur configuration existante. Référencer directement les blocs output correspondants afin que les fichiers générés obsolètes soient supprimés à chaque génération.Source: MCP tools
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@auth-service/src/app.js`:
- Around line 27-30: The documentation endpoints are missing from the OpenAPI
specification and Supertest coverage. Add `@openapi` annotations for
/api/auth/docs.json and /api/auth/docs in auth-service/src/app.js and for
/api/events/docs.json and /api/events/docs in event-service/src/app.js, then add
Jest/Supertest tests that verify their responses.
In `@auth-service/src/config/swagger.js`:
- Line 24: Make the Swagger `apis` configuration independent of the current
working directory by replacing the relative route glob in
`auth-service/src/config/swagger.js:24` and
`event-service/src/config/swagger.js:24` with `path.resolve(import.meta.dirname,
"src/routes/*.js")`, ensuring both files use the appropriate imported path
utility.
In `@event-service/src/routes/events.js`:
- Around line 158-161: Update the event date validation in the affected route to
require date to be a string and conform to the documented ISO 8601 date-time
format before parsing it with new Date. Reject numeric or otherwise malformed
future values, and add a focused test covering a future numeric date such as
99999999999999.
In `@frontend/orval.config.js`:
- Around line 3-8: Update the baseUrl values in the Orval configuration for the
auth and events generated clients to use the exposed /api/auth and /api/events
prefixes instead of /auth and /events. Keep the relative-path behavior
compatible with customInstance, unless an established absolute base URL
configuration already supports both production and local environments.
In `@frontend/src/api/axios-instance.js`:
- Around line 1-11: Ajoutez un test Vitest ciblant customInstance et
l’axiosInstance afin de vérifier la baseURL configurée, le retour de
response.data, la propagation des erreurs et les headers attendus par les
clients générés auth et events. Si le flux de connexion est couvert par cette
PR, ajoutez également un test Playwright correspondant.
- Around line 7-9: Update customInstance to attach the current JWT as a Bearer
Authorization header before calling axiosInstance, using the existing token
source and preserving caller-provided configuration. Ensure generated
protected-service requests are authenticated, and add coverage for a protected
call if the project’s test setup supports it.
In `@knowledge-base/adr/0011-openapi-genere-orval.md`:
- Around line 22-24: Corrigez l’ADR pour indiquer qu’Orval lit les fichiers
OpenAPI locaux générés par les scripts des services, notamment
auth-service/openapi.json et event-service/openapi.json, plutôt que les JSON
exposés par les endpoints HTTP. Conservez la description de la génération
automatique du client frontend.
---
Nitpick comments:
In `@auth-service/src/routes/auth.routes.js`:
- Around line 7-40: Compléter les schémas OpenAPI en ajoutant les champs
required attendus pour User, AuthResponse et Error dans
auth-service/src/routes/auth.routes.js:7-40, pour Event, Pagination et Error
dans event-service/src/routes/events.js:9-54, puis typer la réponse ou le schéma
des claims JWT dans auth-service/src/routes/auth.routes.js:148-154 en
référençant User lorsque les claims correspondent, sinon en créant TokenClaims.
In `@event-service/src/routes/events.js`:
- Around line 63-74: Update the pagination parameter schemas in the events route
documentation to add minimum: 1 for both page and limit, matching the handler’s
lower-bound behavior while preserving their existing defaults and limit maximum.
In `@frontend/orval.config.js`:
- Around line 4-15: Activer l’option clean: true dans les deux configurations de
sortie Orval, les sorties auth et events, en conservant leur configuration
existante. Référencer directement les blocs output correspondants afin que les
fichiers générés obsolètes soient supprimés à chaque génération.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 2cd61fa3-680a-4259-9cdf-5b037c7365b6
⛔ Files ignored due to path filters (3)
auth-service/package-lock.jsonis excluded by!**/package-lock.jsonevent-service/package-lock.jsonis excluded by!**/package-lock.jsonfrontend/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (18)
.gitignoreAGENTS.mdauth-service/package.jsonauth-service/scripts/generate-openapi.jsauth-service/src/app.jsauth-service/src/config/swagger.jsauth-service/src/routes/auth.routes.jsevent-service/package.jsonevent-service/scripts/generate-openapi.jsevent-service/src/app.jsevent-service/src/config/swagger.jsevent-service/src/routes/events.jsfrontend/orval.config.jsfrontend/package.jsonfrontend/src/api/axios-instance.jsknowledge-base/adr/0011-openapi-genere-orval.mdparticipants-service/README.mdregistrations-service/README.md
| app.get("/api/auth/docs.json", (req, res) => { | ||
| res.json(swaggerSpec); | ||
| }); | ||
| app.use("/api/auth/docs", swaggerUi.serve, swaggerUi.setup(swaggerSpec)); |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== repo files relevant =="
git ls-files | rg '(^auth-service/|^event-service/|^swagger-jsdoc|openapi|swagger|test|specs|routes|app\.js)$' | sed -n '1,200p'
echo
echo "== app.js candidates =="
for f in auth-service/src/app.js event-service/src/app.js; do
if [ -f "$f" ]; then
echo "--- $f ---"
wc -l "$f"
cat -n "$f"
else
echo "MISSING $f"
fi
done
echo
echo "== route files =="
for base in auth-service/src/routes event-service/src/routes; do
echo "-- $base --"
if [ -d "$base" ]; then
git ls-files "$base" | sort | while read -r f; do
echo "--- $f ---"
wc -l "$f"
rg -n '`@openapi`|swagger-jsdoc|docs\.json|/docs|swaggerUi|res\.json' "$f" || true
done
else
echo "MISSING $base"
fi
done
echo
echo "== tests files =="
for base in auth-service event-service; do
echo "-- tests under $base --"
git ls-files "$base" | rg '(^|/)(__tests__|test|tests|spec)($|/)|test\.|spec\.' | sort || true
doneRepository: traorecheikh/eventis
Length of output: 2760
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== swagger config candidates =="
for base in auth-service/src/config event-service/src/config; do
if [ -d "$base" ]; then
echo -- "$base" --
git ls-files "$base" | sort | while read -r f; do
echo "--- $f ---"
cat -n "$f" | sed -n '1,220p'
done
else
echo MISSING "$base"
fi
done
echo
echo "== package config/test command =="
for f in auth-service/package.json event-service/package.json; do
[ -f "$f" ] && cat -n "$f" | sed -n '1,160p'
done
echo
echo "== supertest/dotenv docs imports in tests =="
for f in auth-service/tests/auth-service/tests/unit/app-error.test.js auth-service/tests/unit/auth.service.test.js auth-service/tests/integration/auth.routes.test.js event-service/tests/unit/events.routes.test.js event-service/tests/integration/events.integration.test.js; do
[ -f "$f" ] || true
doneRepository: traorecheikh/eventis
Length of output: 5079
Intégrer la documentation aux scans OpenAPI et aux tests Supertest.
swagger-specs ne parcourt que ./src/routes/*.js, donc src/app.js ajoute /docs.json /docs sans route documentée. Ajoutez les endpoints pour /api/auth/docs.json, /api/auth/docs et /api/events/docs.json, /api/events/docs dans les annotations @openapi, puis couvrez leurs réponses avec Jest/Supertest.
📍 Affects 2 files
auth-service/src/app.js#L27-L30(this comment)event-service/src/app.js#L24-L27
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@auth-service/src/app.js` around lines 27 - 30, The documentation endpoints
are missing from the OpenAPI specification and Supertest coverage. Add `@openapi`
annotations for /api/auth/docs.json and /api/auth/docs in
auth-service/src/app.js and for /api/events/docs.json and /api/events/docs in
event-service/src/app.js, then add Jest/Supertest tests that verify their
responses.
Source: Coding guidelines
| } | ||
| } | ||
| }, | ||
| apis: ["./src/routes/*.js"] |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
rg -n 'docs:generate|node src|WORKDIR|working_dir|--prefix|cd ' \
auth-service event-service \
--glob 'package.json' \
--glob 'Dockerfile*' \
--glob '*.yml' \
--glob '*.yaml' || trueRepository: traorecheikh/eventis
Length of output: 807
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '--- swagger configs ---\n'
for f in auth-service/src/config/swagger.js event-service/src/config/swagger.js; do
if [ -f "$f" ]; then
echo "### $f"
cat -n "$f"
fi
done
printf '\n--- route JSDoc examples ---\n'
rg -n '`@openapi`|swagger-ui|swaggerJsDoc|openapi' auth-service src event-service \
--glob '*.js' --glob '*.mjs' || true
printf '\n--- generate-openapi scripts ---\n'
for f in auth-service/scripts/generate-openapi.js event-service/scripts/generate-openapi.js; do
if [ -f "$f" ]; then
echo "### $f"
cat -n "$f"
fi
done
printf '\n--- package scripts ---\n'
for f in auth-service/package.json event-service/package.json; do
echo "### $f"
jq '.scripts' "$f"
done
printf '\n--- server swagger usage ---\n'
for f in auth-service/src/server.js event-service/src/server.js; do
if [ -f "$f" ]; then
echo "### $f"
rg -n -C 4 'swaggerUi|swaggerJsDoc|openapi|documents|serve' "$f" || true
fi
doneRepository: traorecheikh/eventis
Length of output: 249
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- swagger configs ---'
for f in auth-service/src/config/swagger.js event-service/src/config/swagger.js; do
if [ -f "$f" ]; then
echo "### $f"
cat -n "$f"
fi
done
printf '%s\n' ''
printf '%s\n' '--- route JSDoc examples ---'
rg -n '`@openapi`|swagger-ui|swaggerJsDoc|openapi' auth-service src event-service \
--glob '*.js' --glob '*.mjs' || true
printf '%s\n' ''
printf '%s\n' '--- generate-openapi scripts ---'
for f in auth-service/scripts/generate-openapi.js event-service/scripts/generate-openapi.js; do
if [ -f "$f" ]; then
echo "### $f"
cat -n "$f"
fi
done
printf '%s\n' ''
printf '%s\n' '--- package scripts ---'
for f in auth-service/package.json event-service/package.json; do
echo "### $f"
jq '.scripts' "$f"
done
printf '%s\n' ''
printf '%s\n' '--- server swagger usage ---'
for f in auth-service/src/server.js event-service/src/server.js; do
if [ -f "$f" ]; then
echo "### $f"
rg -n -C 4 'swaggerUi|swaggerJsDoc|openapi|documents|serve' "$f" || true
fi
doneRepository: traorecheikh/eventis
Length of output: 5420
🌐 Web query:
swagger-jsdoc directory option apis glob option documentation
💡 Result:
In swagger-jsdoc, the apis option is used to specify the files that contain JSDoc annotations to be parsed for generating your OpenAPI specification [1][2]. The library natively supports glob patterns within this option, allowing you to select multiple files or include entire directory structures [1][3]. When using the apis option in your configuration, you can provide an array of file paths or glob patterns [1][2]. For example: const options = { definition: { openapi: '3.0.0', info: { title: 'API Documentation', version: '1.0.0', }, }, // Using glob patterns to include all.js files in the src directory and its subdirectories apis: ['./src//.js'], }; Key details regarding this functionality include: Glob Support: The library uses the node-glob package to perform file discovery [1]. You can use standard patterns like .js to select all JavaScript files in a directory or /.js to recursively select files across nested subfolders [1][3]. Path Resolution: All paths provided in the apis array are treated as relative to the current working directory [1][3]. Command Line Usage: If you are using the swagger-jsdoc CLI, you can also pass glob patterns directly as arguments [3]. For instance: swagger-jsdoc -d swaggerDefinition.cjs route.js component*.yaml There is no separate directory option required to enable this behavior; the glob patterns provided within the apis property natively handle directory traversal [1][3].
Citations:
- 1: https://github.com/Surnet/swagger-jsdoc/blob/master/docs/CONCEPTS.md
- 2: https://registry.npmjs.org/swagger-jsdoc
- 3: https://github.com/Surnet/swagger-jsdoc/blob/master/docs/CLI.md
Rendre la configuration Swagger indépendante du dossier de travail.
swagger-jsdoc résout apis: ["./src/routes/*.js"] depuis le dossier courant, pas depuis le fichier de configuration. Chaque service démarre avec cmd ou npm dans auth-service / event-service, mais toute exécution depuis un autre dossier produit une spécification sans routes. Utilisez path.resolve(import.meta.dirname, "src/routes/*.js") dans les deux fichiers auth-service/src/config/swagger.js et event-service/src/config/swagger.js.
📍 Affects 2 files
auth-service/src/config/swagger.js#L24-L24(this comment)event-service/src/config/swagger.js#L24-L24
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@auth-service/src/config/swagger.js` at line 24, Make the Swagger `apis`
configuration independent of the current working directory by replacing the
relative route glob in `auth-service/src/config/swagger.js:24` and
`event-service/src/config/swagger.js:24` with `path.resolve(import.meta.dirname,
"src/routes/*.js")`, ensuring both files use the appropriate imported path
utility.
| * date: | ||
| * type: string | ||
| * format: date-time | ||
| * description: ISO 8601, doit etre strictement dans le futur |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== locate file =="
git ls-files | grep -E '(^|/)event-service/src/routes/events\.js$|event-service/package\.json|event-service/package-lock\.json' || true
echo "== relevant file outline/lines =="
if [ -f event-service/src/routes/events.js ]; then
wc -l event-service/src/routes/events.js
sed -n '120,230p' event-service/src/routes/events.js | cat -n
fi
echo "== search date validation references =="
rg -n "date-time|date:|new Date\\(|request\\.body|bodyParams|validation|swagger-jsdoc|JSDoc|`@openapi`" event-service/src -S || true
echo "== inspect package scripts/deps =="
if [ -f event-service/package.json ]; then
cat event-service/package.json
fiRepository: traorecheikh/eventis
Length of output: 5908
🌐 Web query:
swagger-jsdoc version 6 validate request body date-time format swagger-jsdoc
💡 Result:
swagger-jsdoc is a tool used to generate an OpenAPI specification from JSDoc-annotated code; it does not perform runtime request body validation itself [1][2]. Because it is a documentation generator rather than a middleware or validation engine, you must use other tools to enforce that a request body adheres to a specified date-time format at runtime [1][2][3]. To validate that a request body matches a specific date-time format: 1. Define the Schema in JSDoc: Use the OpenAPI specification syntax within your JSDoc comments to define the field as a string with the date-time format [4][3]. This informs consumers of your API about the expected format [3]. Example: * @openapi * /example: * post: * requestBody: * content: * application/json: * schema: * type: object * properties: * timestamp: * type: string * format: date-time * description: 'An RFC 3339 date-time string (e.g., 2026-08-09T12:00:00Z)' 2. Implement Runtime Validation: Since swagger-jsdoc only produces documentation, you should integrate a separate validation library into your Node.js application to enforce this schema at runtime [1][2]. Common choices include: - Joi: You can create a Joi schema that validates the format and potentially use tools like joi-to-swagger to sync this with your OpenAPI definitions [5]. - express-openapi-validator: This library can automatically validate incoming requests against your generated OpenAPI specification. - Ajv (Another JSON Schema Validator): Commonly used to validate request bodies against JSON schemas generated from your OpenAPI definitions. By separating documentation generation (swagger-jsdoc) from runtime enforcement (e.g., Ajv, Joi), you ensure your API is both well-documented and robustly validated [1][3].
Citations:
- 1: https://github.com/Surnet/swagger-jsdoc/tree/v6
- 2: https://registry.npmjs.org/swagger-jsdoc
- 3: https://swagger.io/docs/specification/v3_0/data-models/data-types/
- 4: https://swagger.io/docs/specification/v3_0/describing-request-body/describing-request-body/
- 5: Options to pass components Schema to swaggerJsdoc Surnet/swagger-jsdoc#311
🏁 Script executed:
#!/bin/bash
set -euo pipefail
node - <<'JS'
const valid = "2030-12-01T12:00:00Z";
const isoFuture = "2030-12-0112:00";
const numericFuture = 99999999999999;
for (const value of [valid, isoFuture, numericFuture]) {
const parsedDate = new Date(value);
const iso = parsedDate && Number.isNaN(Number(parsedDate)) ? "invalid Date object" : new Date(parsedDate).toJSON();
console.log(JSON.stringify({ value, parsed: parsedDate.toJSON(), futureValid: parsedDate && Number.isNaN(Number(parsedDate)) ? false : parsedDate > new Date(), iso }));
}
JSRepository: traorecheikh/eventis
Length of output: 482
Contrôlez aussi le type et le format de date.
swagger-jsdoc ne valide que la documentation ; le routeur accepte aussi un numéro futur comme 99999999999999 car new Date(...) le parse en date JavaScript. Ajoutez un test exclusif typeof date === "string" et un format ISO conforme, ou ajustez le schéma format pour que la validation runtime corresponde au contrat.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@event-service/src/routes/events.js` around lines 158 - 161, Update the event
date validation in the affected route to require date to be a string and conform
to the documented ISO 8601 date-time format before parsing it with new Date.
Reject numeric or otherwise malformed future values, and add a focused test
covering a future numeric date such as 99999999999999.
| input: "../auth-service/openapi.json", | ||
| output: { | ||
| mode: "tags-split", | ||
| target: "./src/api/generated/auth", | ||
| client: "axios", | ||
| baseUrl: "/auth", |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
rg -n -C 3 \
'VITE_API_BASE_URL|baseURL|baseUrl|/api/auth|/api/events' \
. \
--glob '*.{js,mjs,vue,md,json,yml,yaml}' || trueRepository: traorecheikh/eventis
Length of output: 30820
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- frontend package ---'
sed -n '1,140p' frontend/package.json
printf '%s\n' '--- orval config ---'
cat -n frontend/orval.config.js
printf '%s\n' '--- axios instance ---'
cat -n frontend/src/api/axios-instance.js
printf '%s\n' '--- Vite env/public files ---'
for f in .env .env.example frontend/.env frontend/.env.example frontend/vite.config.js frontend/vite.config.mjs frontend/public/.env frontend/public/.env.example; do
[ -e "$f" ] && { echo "### $f"; sed -n '1,160p' "$f"; }
done
printf '%s\n' '--- generated or generated-like dirs ---'
find frontend -type f \( -name '*.js' -o -name '*.vue' \) | sed -n '1,120p'Repository: traorecheikh/eventis
Length of output: 4633
🌐 Web query:
orval 8 axios baseUrl configured baseUrl merge with generated path axiosInstance
💡 Result:
In Orval, the baseUrl configured in your orval.config.js output options and the baseUrl defined within an injected Axios instance serve different purposes, but they do not automatically "merge" in the way you might expect if you are using a custom mutator or instance [1][2]. When using the default Axios client generator, Orval uses the baseUrl specified in your output configuration to construct the requests [2][3]. If you also inject a custom Axios instance (via the factory function provided by Orval) that has its own baseURL set, the behavior depends on how that instance is implemented [1][3]. Here is how to manage this: 1. Recommended Approach: Use Orval's native baseUrl configuration. If you define baseUrl in your orval.config.js output settings, Orval manages the concatenation of the base URL and the generated path automatically [2]. 2. Custom Axios Instance: If you need a custom Axios instance (e.g., for interceptors or auth tokens), you should define the baseURL inside that instance [1]. If you use a custom Axios instance, the baseURL in your orval.config.js may be redundant or could conflict depending on how the instance handles incoming request configurations. If you are using a mutator, you are responsible for how the URL is constructed within that mutator function [1][4]. 3. Merging Behavior: Axios itself does not automatically merge two base URLs if you provide a full URL to an instance that already has a baseURL. If your generated path is relative (e.g., /pets) and your custom instance has a baseURL (e.g., https://api.com), Axios will combine them to https://api.com/pets [1]. If your generated path includes a domain or you are using a mutator that explicitly concatenates strings, you must ensure you handle the path logic manually to avoid double-slashes or incorrect URL construction [1][4]. To ensure a clean configuration, it is generally recommended to either: - Rely on Orval's output.baseUrl and use a default Axios instance [2]. - Or define your custom Axios instance with the necessary baseURL and keep output.baseUrl empty or unset to avoid conflicts [1][3].
Citations:
- 1: https://orval.dev/docs/guides/custom-axios
- 2: https://orval.dev/docs/guides/set-base-url
- 3: https://orval.dev/docs/reference/configuration/output/
- 4: https://orval.dev/docs/guides/custom-client
🌐 Web query:
orval 8.24.0 custom mutator axios baseUrl request.config.url absolute
💡 Result:
In Orval (including version 8.24.0), handling baseURL when using a custom mutator with Axios requires understanding how Axios request configurations interact with baseURL [1][2]. When you provide a custom mutator, Orval passes the generated request configuration (which includes the URL path from your OpenAPI spec) to your mutator function [1][3]. If your Axios instance has a defined baseURL, Axios automatically handles the concatenation of the baseURL and the request URL [1][4]. Regarding the behavior of absolute URLs: 1. Standard Axios Behavior: By default, if the url provided in the request configuration is an absolute URL (e.g., starting with http:// or https://), Axios will ignore the baseURL and use the absolute URL instead [4]. 2. Overriding: If you want to ensure the baseURL is always used regardless of the generated URL, you must handle this logic inside your custom mutator [1][3]. Since your mutator receives the full AxiosRequestConfig, you can inspect and manipulate the url field before passing it to your Axios instance [1][5]. If your goal is to handle dynamic base URLs (such as process.env.API_BASE_URL) without writing a custom mutator, Orval provides built-in support for runtime base URLs via the configuration object [2]: export default defineConfig({ petstore: { output: { baseUrl: 'process.env.API_BASE_URL', }, }, }); Orval automatically wraps this expression into template literals for the generated code [2]. If you must use a custom mutator, you can keep your Axios instance clean by creating it with the desired baseURL and simply passing the Orval-provided config object through to it, allowing Axios to apply its native baseURL logic [1]: // Custom Mutator Example import Axios, { AxiosRequestConfig } from 'axios'; const AXIOS_INSTANCE = Axios.create({ baseURL: 'https://api.example.com' }); export const customInstance = (config: AxiosRequestConfig): Promise => { return AXIOS_INSTANCE(config).then(({ data }) => data); }; If the url in config is relative, it will be prepended by the baseURL. If your OpenAPI specification generates absolute URLs and you wish to force the baseURL, you must explicitly modify the url within the mutator to be relative or strip the host before passing it to AXIOS_INSTANCE [4].
Citations:
- 1: https://orval.dev/docs/guides/custom-axios
- 2: https://orval.dev/docs/reference/configuration/output/
- 3: https://orval.dev/docs/guides/custom-client
- 4: https://axios.rest/pages/advanced/request-config
- 5: How to config differnet baseURLs for different input files? orval-labs/orval#1611
🌐 Web query:
site:github.com/orval-labs/orval orval 8 axios generated config url baseUrl mutator config.url
💡 Result:
In Orval, configuring the baseUrl for your generated API clients and using a custom mutator are handled as distinct, complementary configuration options within your orval.config.ts file [1][2]. ### Configuring baseUrl The baseUrl property is defined within the output section of your configuration [1][3]. It is used to prefix the API endpoint paths generated by Orval [2]. Example configuration: typescript // orval.config.ts export default defineConfig({ api: { input: './openapi.json', output: { target: 'src/api/endpoints.ts', baseUrl: 'https://api.example.com/v1', // Base URL for generated endpoints override: { mutator: { path: './src/api/mutator/custom-instance.ts', name: 'customInstance', }, }, }, }, }); ### Using a Custom Mutator While baseUrl manages the path construction, a custom mutator is used to define the HTTP client instance (e.g., Axios or Fetch) that executes the requests [4][5]. Orval passes a configuration object to your mutator for every request, which includes the URL [4]. 1. Define your custom instance (e.g., src/api/mutator/custom-instance.ts): typescript import Axios, { AxiosRequestConfig } from 'axios'; // You can define your instance here with any global defaults export const customInstance = Axios.create({ baseURL: 'https://api.example.com/v1', // Optional: You may also set it here }); export const request = <T>(config: AxiosRequestConfig): Promise<T> => { return customInstance.request(config).then((res) => res.data); }; 2. Reference it in your orval.config.ts [6][7]: typescript override: { mutator: { path: './src/api/mutator/custom-instance.ts', name: 'request', // Name of the exported function Orval calls }, }, ### Important Considerations * Path Prefixes: When you provide a baseUrl in your config, Orval prepends it to the API paths [2]. If you also set a baseURL within your Axios instance, ensure you are not inadvertently doubling the base path, depending on how your mutator handles the config.url parameter [1][8]. * Runtime baseUrl: If you need a dynamic base URL at runtime (e.g., from an environment variable), Orval generates the baseUrl string into the code at build time [9]. For truly runtime-dynamic URLs, it is often recommended to manage the base URL inside your custom Axios instance configuration rather than relying on Orval's static baseUrl option [9][8]. * Mutation Invalidation: Note that if you use baseUrl in your config, query keys generated by Orval will be prefixed with this URL [2]. If you are using features like mutationInvalidates, ensure your invalidation logic accounts for this prefix [2].
Citations:
- 1: How to config differnet baseURLs for different input files? orval-labs/orval#1611
- 2: Mutation invalidates misses keys with they are prefixed with base URL orval-labs/orval#3534
- 3:
baseUrldoes not acceptObjectindefineConfigtype helper orval-labs/orval#1787 - 4: https://github.com/orval-labs/orval/blob/master/packages/axios/src/index.ts
- 5: How to pass axios options per query orval-labs/orval#282
- 6: https://github.com/orval-labs/orval/blob/master/samples/react-app/orval.config.ts
- 7: https://github.com/orval-labs/orval/blob/5a425ba6/samples/react-query/basic/orval.config.ts
- 8: Incorrect "Your mutator cannot be loaded so default setup has been applied" warning? orval-labs/orval#257
- 9: Fetch: Support runtime baseUrl (e.g. process.env) without custom mutator orval-labs/orval#3071
🌐 Web query:
orval 8.24.0 source packages orval packages axios src generators.ts baseUrl client
💡 Result:
In Orval, the baseUrl configuration and client generation logic are primarily handled within the output configuration and the core generator packages. Configuration of the baseUrl is defined in the output section of your orval.config.ts file [1]. Orval supports static base URLs, base URLs derived from the OpenAPI specification, and runtime base URLs for dynamic environments [2][3]. The configuration interface for these options is defined in packages/core/src/types.ts [2]. The client generation logic is managed in packages/orval/src/client.ts, which orchestrates the generation of operations by selecting the appropriate client generator (e.g., axios, react-query, fetch) [4]. When you specify a client such as axios, Orval uses built-in generator functions to map your API definitions to the chosen HTTP client library [4]. If you require advanced customization of the client—such as injecting custom Axios instances, interceptors, or specific base URL handling—it is recommended to use the mutator pattern [5]. By configuring a mutator in the override section of your output settings, you can point to a custom implementation file that wraps your HTTP client, providing full control over the instance configuration (including baseURL) at runtime [5][6]. For specific details regarding the source code structure, packages/core/src/generators/ contains the logic for creating various code artifacts like interfaces, imports, and schema definitions [7][8][9]. The main execution flow for generating these files is initiated in packages/orval/src/generate.ts [10].
Citations:
- 1: https://orval.dev/docs/reference/configuration/output/
- 2: https://github.com/orval-labs/orval/blob/master/packages/core/src/types.ts
- 3: https://orval.dev/docs/guides/set-base-url
- 4: https://github.com/orval-labs/orval/blob/5a425ba6/packages/orval/src/client.ts
- 5: https://orval.dev/docs/guides/custom-axios/
- 6: Question: Limitations of client instance customisation orval-labs/orval#1373
- 7: https://github.com/orval-labs/orval/blob/master/packages/core/src/generators/schema-definition.ts
- 8: https://github.com/orval-labs/orval/blob/5a425ba6/packages/core/src/generators/interface.ts
- 9: https://github.com/orval-labs/orval/blob/5a425ba6/packages/core/src/generators/imports.ts
- 10: https://github.com/orval-labs/orval/blob/master/packages/orval/src/generate.ts
🌐 Web query:
orval axios client generator config.url orval.options.baseUrl customInstance mutator axios.config.url
💡 Result:
To configure a custom Axios client in Orval, you use a mutator function defined in your orval.config.ts. This allows you to intercept or wrap every API request made by the generated client [1][2]. 1. Configure the Mutator In your orval.config.ts, point to your custom mutator function [1][2]: export default defineConfig({ petstore: { output: { httpClient: 'axios', override: { mutator: { path: './api/mutator/custom-instance.ts', name: 'customInstance', }, }, }, }, }); 2. Implement the Mutator In your mutator file (e.g.,./api/mutator/custom-instance.ts), create a custom Axios instance [1][3]. You can define a base URL here to handle your API host [1][4]. The mutator function receives the request configuration and optionally request-specific options [1][5]. import Axios, { AxiosRequestConfig } from 'axios'; // Define your custom instance export const AXIOS_INSTANCE = Axios.create({ baseURL: process.env.API_URL, // Set your dynamic or hardcoded base URL here }); // The custom instance function export const customInstance = ( config: AxiosRequestConfig, options?: AxiosRequestConfig,): Promise => { return AXIOS_INSTANCE({...config,...options, // Merges global config with per-request overrides }).then(({ data }) => data); }; Key Concepts: - Axios.config.url vs baseUrl: The Orval output.baseUrl setting in the config file is used for generating the base path within the client [4][6]. However, using a custom Axios instance with a defined baseURL is the recommended way to handle dynamic runtime URLs (e.g., from environment variables) or custom Axios configurations [1][4]. - Mutator Arguments: The customInstance function typically accepts two arguments: config (containing generated request details like URL, method, and params) and an optional second argument (options) that allows you to pass additional per-request configuration, such as specific headers or request-level axios overrides [1][7][5]. - Flexibility: Because you are defining the Axios instance yourself, you can easily add interceptors (e.g., for JWT auth) or specific configurations directly to the AXIOS_INSTANCE object rather than relying on Orval's generated defaults [1][3].
Citations:
- 1: https://orval.dev/docs/guides/custom-axios
- 2: https://orval.dev/docs/guides/custom-client
- 3: https://orval.dev/docs/guides/custom-axios/
- 4: https://orval.dev/docs/guides/set-base-url/
- 5: Pass an additional option object in fetcher function when using custom axios instance orval-labs/orval#1233
- 6: https://orval.dev/docs/reference/configuration/output/
- 7: React Query: Support passing
query.meta/mutation.metaoptions to axios instance orval-labs/orval#1317
🌐 Web query:
github.com/orval-labs/orval/blob/master/packages/axios/src/index.ts orval 8.24.0 axios
💡 Result:
Orval version 8.24.0 was released on August 8, 2026 [1]. The file located at packages/axios/src/index.ts is part of the Orval codebase and handles the generation of Axios-based API clients [2][3]. In Orval v8, the library transitioned to using fetch as the default HTTP client [4]. However, the @orval/axios package remains available for projects that prefer or require Axios [5]. Key characteristics of the implementation in packages/axios/src/index.ts include: - Factory Pattern: The module supports a factory pattern, allowing for dependency injection of custom Axios instances [3][6]. This enables users to configure instances with specific interceptors, base URLs, or authentication headers independently of the generated client [7][8]. - Client Builders: The code uses builder objects (such as axiosClientBuilder) to define how the Axios client, headers, and dependencies are generated [2][3]. - Recent Changes: In recent versions leading up to 8.24.0, the Axios package underwent internal refactoring, such as eliminating module-level maps for return types to improve stability and modularity [9]. For projects needing Axios, you can configure Orval to use it by setting the httpClient option in your configuration file: output: { client: 'react-query', // or other client types httpClient: 'axios', } Using Orval with a custom Axios instance is the recommended approach for managing advanced configurations like dynamic authentication tokens or custom error handling [7].
Citations:
- 1: https://newreleases.io/project/npm/orval/release/8.24.0
- 2: https://github.com/orval-labs/orval/blob/master/packages/axios/src/index.ts
- 3: https://github.com/orval-labs/orval/blob/5a425ba6/packages/axios/src/index.ts
- 4: https://orval.dev/docs/versions/v8
- 5: https://www.npmjs.com/package/%40orval%2Faxios
- 6: feat(axios): add factory pattern for HTTP client dependency injection orval-labs/orval#2851
- 7: https://orval.dev/docs/guides/custom-axios
- 8: feat: add a way to provide an axios instance orval-labs/orval#2423
- 9: fix(axios): eliminate module-level returnTypesToWrite map orval-labs/orval#3696
Faites correspondre baseUrl avec le préfixe d’API exposé.
La documentation et les routes définissent les bases de la passerelle sous /api/auth et /api/events, mais Orval génére des clients avec /auth et /events. Avec customInstance, une valeur absolue comme https://paruwa.xyz/api ne sera pas concaténée avec les chemins relatifs générés par défaut. Alignez ./frontend/orval.config.js au préfixe réel, ou indiquez une valeur absolue complète avec baseUrl pour couvrir production et local.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@frontend/orval.config.js` around lines 3 - 8, Update the baseUrl values in
the Orval configuration for the auth and events generated clients to use the
exposed /api/auth and /api/events prefixes instead of /auth and /events. Keep
the relative-path behavior compatible with customInstance, unless an established
absolute base URL configuration already supports both production and local
environments.
Source: MCP tools
| import axios from "axios"; | ||
|
|
||
| const axiosInstance = axios.create({ | ||
| baseURL: import.meta.env.VITE_API_BASE_URL || "/api" | ||
| }); | ||
|
|
||
| export const customInstance = (config) => { | ||
| return axiosInstance(config).then((response) => response.data); | ||
| }; | ||
|
|
||
| export default customInstance; |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
rg -n -C 3 \
'customInstance|axios-instance|generate:api|generated/auth|generated/events' \
frontend \
--glob '*.{test,spec}.{js,ts}' || trueRepository: traorecheikh/eventis
Length of output: 158
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Tracked files under frontend:"
git ls-files 'frontend/**' | sed -n '1,220p'
echo
echo "Locate axios instance, generated api files, and test specs:"
fd -a 'axios-instance|auth|events|test|spec' frontend | sed -n '1,240p' | sort
echo
echo "Search customInstance/import from axios-instance across frontend:"
rg -n 'customInstance|from ["'\'']\.?/axios-instance|from ["'\''](axios-instance)|generate:api|generated/(auth|events)|Playwright|playwright' frontend || trueRepository: traorecheikh/eventis
Length of output: 1302
Ajoutez un test Vitest pour customInstance.
customInstance est le mutateur partagé par les clients générés auth et events, mais son fichier n’a aucun test frontend. Ajoutez un test qui couvre la base URL finale, le retour de response.data, la propagation des erreurs, et les headers utilisés par ces appels. Si cette PR couvre le flux de connexion, ajoutez aussi un test Playwright.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@frontend/src/api/axios-instance.js` around lines 1 - 11, Ajoutez un test
Vitest ciblant customInstance et l’axiosInstance afin de vérifier la baseURL
configurée, le retour de response.data, la propagation des erreurs et les
headers attendus par les clients générés auth et events. Si le flux de connexion
est couvert par cette PR, ajoutez également un test Playwright correspondant.
Source: Coding guidelines
| export const customInstance = (config) => { | ||
| return axiosInstance(config).then((response) => response.data); | ||
| }; |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
rg -n -C 4 \
'bearerAuth|security:|Authorization|localStorage|sessionStorage|cookie|customInstance' \
auth-service event-service frontend \
--glob '*.{js,mjs,vue,json,md}' || trueRepository: traorecheikh/eventis
Length of output: 21039
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== frontend generated files =="
git ls-files frontend | rg 'generated|api|client|orval|axios' || true
echo
echo "== frontend/api files =="
for f in $(git ls-files frontend/src/api 2>/dev/null || true); do
echo "--- $f"
cat -n "$f"
done
echo
echo "== frontend package scripts/deps =="
node -e 'const p=require("./frontend/package.json"); console.log(JSON.stringify({scripts:p.scriptsdependencies:p.dependenciesdevDependencies:p.devDependenciesorval:p.devDependencies?.orval},null,2))'
echo
echo "== frontend generated auth/events client references =="
rg -n -C 3 "import \{|\.get|\.post|\.put|\.patch|\.delete|Bearer|Authorization|token|authenticate|me|events|customInstance" frontend || trueRepository: traorecheikh/eventis
Length of output: 1301
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== all frontend files tracked in src =="
git ls-files frontend/src || true
echo
echo "== frontend package =="
cat -n frontend/package.json
echo
echo "== generated client files in frontend src =="
for f in $(git ls-files frontend/src 2>/dev/null | grep -E '(generated|api|client|orval|auth|event)' || true); do
echo "--- $f"
sed -n '1,220p' "$f"
done
echo
echo "== broad frontend references =="
rg -n -C 3 "generated|authClient|event|events|customInstance|axiosInstance|Bearer|Authorization|token|me|GET|POST|PUT|DELETE|PATCH" frontend || trueRepository: traorecheikh/eventis
Length of output: 28785
Transmettez le JWT dans le mutator Orval.
customInstance appelle axiosInstance(config) sans ajouter de header Authorization. Les événements protégés utilisent bearerAuth, donc tout client généré restera non authentifié sauf interception du jeton. Ajoutez un interceptor de requête dans ce mutator qui lit la source de jeton, ou générez un mutator par service avec injection d’optionnellement le bearer. Couvrez un appel protégé avec Playwright/Vitest.
[security_and_privACY]
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@frontend/src/api/axios-instance.js` around lines 7 - 9, Update customInstance
to attach the current JWT as a Bearer Authorization header before calling
axiosInstance, using the existing token source and preserving caller-provided
configuration. Ensure generated protected-service requests are authenticated,
and add coverage for a protected call if the project’s test setup supports it.
Source: MCP tools
| 2. **Le client frontend est genere, jamais ecrit a la main.** Orval lit le | ||
| JSON expose par chaque service et genere un client Axios type dans | ||
| `frontend/src/api/generated/<service>/`. |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win
Corrigez la description de la source lue par Orval.
Cette ADR indique qu’Orval lit le JSON exposé par chaque service. En réalité, frontend/orval.config.js, Line [3] et Line [18], utilise les fichiers locaux ../auth-service/openapi.json et ../event-service/openapi.json. La commande npm run generate:api ne consomme pas directement /api/auth/docs.json ou /api/events/docs.json.
Indiquez que les scripts des services écrivent d’abord les fichiers locaux, ou modifiez la configuration pour utiliser les URL HTTP.
Correction proposée
- JSON expose par chaque service et genere un client Axios type dans
+ les fichiers `openapi.json` générés localement par chaque service et génère un client Axios typé dans
`frontend/src/api/generated/<service>/`.🧰 Tools
🪛 LanguageTool
[typographical] ~23-~23: Caractère d’apostrophe incorrect.
Context: ...ice et genere un client Axios type dans frontend/src/api/generated/<service>/. 3. Ni openapi.json ni `frontend/src/...
(APOS_INCORRECT)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@knowledge-base/adr/0011-openapi-genere-orval.md` around lines 22 - 24,
Corrigez l’ADR pour indiquer qu’Orval lit les fichiers OpenAPI locaux générés
par les scripts des services, notamment auth-service/openapi.json et
event-service/openapi.json, plutôt que les JSON exposés par les endpoints HTTP.
Conservez la description de la génération automatique du client frontend.
…r 2 avec justification Trouvailles appliquees, verifiees en conditions reelles : - pagination : minimum: 1 sur page et limit dans le schema (correspond au comportement du handler) - schemas OpenAPI incomplets : required sur User, AuthResponse, Error, Event, Pagination. /me referencait un objet non type, remplace par un nouveau schema TokenClaims (id, email, role, iat, exp) - orval.config.js : clean: true sur les deux sorties, evite des fichiers generes perimes quand une route ou un tag disparait - swagger.js apis independant du cwd : resolve(import.meta.dirname, ...) au lieu d'un chemin relatif fragile - faille de validation reelle : date pouvait etre un nombre (epoch ms), new Date(nombre) le convertit en date valide et contourne le contrat "chaine ISO 8601". Ajoute typeof date !== "string" avant le parsing, plus un test dedie (date: 99999999999999) - axios-instance.js n'attachait jamais le jeton JWT : tout appel genere vers une route protegee (POST /events) aurait echoue en 401 sans que l'appelant ajoute lui-meme un header. Ajoute setAuthToken()/clearAuthToken() plus un intercepteur de requete - ADR 0011 disait qu'Orval lit le JSON expose par HTTP, alors qu'il lit le fichier local openapi.json ecrit par docs:generate. Corrige - tests Jest/Supertest ajoutes pour /docs et /docs.json sur les deux services (existaient, verifies seulement a la main jusqu'ici) Trouvailles ecartees, avec justification (pas silencieusement ignorees) : - orval.config.js baseUrl "/api/auth"/"/api/events" plutot que "/auth"/ "/events" : la suggestion suppose qu'axios-instance.js n'a pas deja VITE_API_BASE_URL=/api en baseURL. Avec la config actuelle, appliquer cette suggestion doublerait le prefixe (/api/api/auth/...) et casserait exactement le test de bout en bout deja verifie fonctionnel. Config actuelle correcte, non modifiee. - annotations @openapi pour les routes /docs et /docs.json elles-memes : documentation auto-referentielle non standard (aucun projet Swagger ne documente sa propre interface Swagger UI comme une operation d'API). Couverture de test ajoutee a la place (voir ci-dessus), qui apporte la vraie valeur de la suggestion. - test Vitest pour axios-instance.js : Vitest n'est pas encore installe dans frontend/ (suivi comme ecart connu dans AGENTS.md section "Etat du depot"), bootstrap complet hors perimetre de ce fix. Tout reverifie en conditions reelles apres application : suites de tests des deux services toujours vertes (16+16), specs regenerees, client Orval regenere avec clean: true confirme actif, et un nouveau test de bout en bout complet (inscription, setAuthToken, creation d'evenement protegee via le client genere sans aucun header ajoute a la main) execute contre la stack docker compose reelle a travers la passerelle.
e3b9b23 to
6ce6e75
Compare
Reponse aux 7 trouvailles CodeRabbitEgalement supprime le trailer Appliquees, verifiees en conditions reelles
Ajoute aussi les tests Jest/Supertest pour Ecartees, avec justification
Reverifie apres application
|
Description
Le README annoncait des routes Swagger jamais implementees (aucune dependance dans les package.json, aucune route de docs). Implemente reellement, avec generation stricte (jamais de spec ou de client ecrit a la main).
@openapisur chaque route, servi sur/api/<service>/docs(UI) et/docs.json(JSON)npm run docs:generatedans chaque service ecritopenapi.json(gitignore, regenerable)frontend/src/api/generated/(gitignore, regenerable vianpm run generate:api)Type de changement
Comment tester
Verifie en conditions reelles, pas seulement compile :
docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d --buildpuiscurl http://localhost/api/auth/docs.jsonetcurl http://localhost/api/events/docs.jsona travers la vraie passerelle : 200, contrat correctauth-serviceen cours d'execution (base ephemere) : inscription puis connexion reussies via les fonctions generees, pas juste une verification de syntaxeSummary by CodeRabbit