feat(server-nestjs): migrer vers Zod 4 (catalog runtime + @ts-rest ClientInfer->z.infer) - #2559
Closed
shikanime wants to merge 1 commit into
Closed
feat(server-nestjs): migrer vers Zod 4 (catalog runtime + @ts-rest ClientInfer->z.infer)#2559shikanime wants to merge 1 commit into
shikanime wants to merge 1 commit into
Conversation
shikanime
force-pushed
the
feat/zod4-migration
branch
2 times, most recently
from
August 24, 2026 17:58
df283fa to
5c9b030
Compare
Keep @cpn-console/shared, @cpn-console/hooks, apps/server and apps/client on zod 3. Pin only apps/server-nestjs to zod ^4.4.3 as a direct dependency so zod 4 stays nested under server-nestjs. Root cause of the earlier CI failures: @anatine/zod-openapi (reached via @ts-rest/open-api in apps/server) declares a zod peer range `^3.22 || ^4`. As soon as zod 4 existed anywhere in the workspace, pnpm resolved it to zod 4, which dragged @ts-rest/core (apps/server) onto zod 4 and broke the @ts-rest AppRouter contract typing (zod-3 ZodObject missing zod-4 internals). Fix: - pnpm-workspace.yaml: override `@anatine/zod-openapi>zod` to 3.25.76 so apps/server's @ts-rest subtree stays on zod 3 (matches main). - apps/server-nestjs/package.json: zod ^4.4.3; drop the unused @ts-rest/core / @ts-rest/fastify / @ts-rest/open-api declarations (0 source imports) that also pulled zod 4 into the shared graph. - src/config/validators.ts: localize atomicValidators / pluginConfig / editStrippersGenerator / editStrippers (zod-4 copies of the shared/hooks zod-3 values) to avoid crossing the schema-major boundary at runtime (.merge of a zod-3 schema into a zod-4 object throws). - project-services.utils.ts & system-config.service.ts: consume the localized validators instead of the zod-3 exports from shared/hooks. - zod-4 internal config fixes (base.config, config.utils, keycloak utils, version-agnostic ZodValidationPipe). Verified: shared/hooks/apps-server/client byte-identical to main; apps/server AppRouter error resolved; server-nestjs builds + 574 tests pass; shared 74 + hooks 17 tests pass. Related: #2558 Signed-off-by: William Phetsinorath <william.phetsinorath-open@interieur.gouv.fr> Change-Id: Ib9877eaacb3e1de19186b24d277c0dd56a6a6964
shikanime
force-pushed
the
feat/zod4-migration
branch
from
August 24, 2026 18:27
5c9b030 to
f608926
Compare
|
Member
Author
|
Not feasible because of legacy server |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

3 New Issues
0 Fixed Issues
0 Accepted Issues
Issues liées
#2558
Quel est le comportement actuel ?
apps/server-nestjsutilise Zod 3 via le catalogruntime, et dérive ses types de contrat@ts-restviaClientInferRequest/ClientInferResponseBody.@ts-rest/core@3.52.1lit les internals Zod 3 : face à des schémas Zod 4, ces types résolvent enneveret empoisonnent ~36 types dérivés (ProjectV2,CreateProjectBody, etc.).Quel est le nouveau comportement ?
runtimepasse àzod ^4.4.3(etzod-validation-error ^5.0.0).@cpn-console/sharedetapps/server(gelé) restent sur Zod 3.@ts-rest/*n'est pas remonté en version : on substitue nativementz.infer<typeof contrat.route.body/query/params/responses[200]>aux sitesClientInfer*danspackages/shared/src/contracts/*(26 sites). Aucun typeneverrésiduel.pluginUpdateBodycorrigé enz.record(z.string(), z.record(z.string(), z.string()))(forme imbriquée 2 niveaux valide en Zod 4).z._type->z.infer,SafeParseReturnType->ZodSafeParseResult,ZodError.flatten,z.string().url()/.ip()/.cidr(),z.recordà 2 arguments, pipe de transform.@ts-rest/*retiré deapps/server-nestjs/package.json(0 import source vérifié).Cette PR introduit-elle un breaking change ?
Non pour l'API.
apps/server(Zod 3) n'est pas modifié ; l'isolation de catalog évite toute régression de type runtime.Autres informations
Vérifications :
shared/hooks/logger/server-nestjsbuild verts (zod 4.4.3 partout),pnpm run buildnest sans erreur, vitestserver-nestjs574 passés / 0 échoué (16 skippés). Le test anciennement refusant (project-services.service.spec.ts) passe désormais.Mise à niveau de dépendance : nécessite l'approbation de l'équipe CPiN pour le merge (conformément à CONTRIBUTING.md).