[MatheusAndrade23]

Contexto

TIM-3679. No tim-network-adapter, o @pact-foundation/pact instala express@^5 na raiz. O framework declarava express@^4 como peer, então o npm aninhava uma cópia do framework em cada workspace. Cada cópia tinha seu próprio AsyncLocalStorage, e o x-correlation-id gravado pela unit não chegava aos clients do libs.

O que muda

• Breaking change: os peers express e @types/express passam a ser ^5.0.0, e continuam opcionais. Serviços que usam controllers, middlewares ou auth-permission/express com express 4 precisam migrar para o express 5 antes de subir para a 1.0.0. Serviços com Fastify ou Hono não são afetados.
• expressRegisterPermissionAuth: o middleware agora é async. Uma falha do validator (rejeição da promise) vai para o error handler pelo tratamento nativo de promises do express 5.
• Dev deps: express@5.3.0 e @types/express@5.0.6.
• Dependências de runtime: mathjs 14 → 15 e os minors uuid 11.1, hono 4.13, zod 4.6, date-fns 4.4, winston 3.19 e @fastify/rate-limit 11.2.1. Todas mantêm build CommonJS e suportam Node 20.
• Versão: 1.0.0. É uma breaking change, então sobe o major (semver, conforme o AGENTS.md).

Impacto nos consumidores

Serviço	framework	express
wave-usage-api	^0.16.0	^4.21.2
wave-experience-api	^0.1.3	^4.18.2
telcel-journeys-bff	^0.1.3	^4.22.1
telcel-omni-hub-api	^0.1.3	^4.21.2
wave-offers-api	^0.1.3	^4.21.2

Nenhum deles quebra agora, porque o caret (^0.x) não pega a 1.0.0. Eles só precisam migrar para o express 5 quando subirem o framework. No tim-network-adapter, o bump fica no TIM-3729.

Como testar

• pnpm lint, pnpm build e pnpm test (260 testes) passam com express 5. A spec do expressRegisterPermissionAuth sobe um app express 5 real e cobre a falha do validator indo para o error handler (503/401).
• Smoke test com o pacote gerado por npm pack:
  • Num consumidor com express@5, o npm deixa uma única cópia do express (express@5.3.0 deduped sob o framework). O tsc --strict passa, e a requisição devolve o x-correlation-id recebido. A rejeição async do validator chega ao error handler.
  • Num consumidor com express@4, o npm i falha com ERESOLVE no peer express@"^5.0.0".
  • No Node 20.0 e no 22.23, Uuid.fromSeed (uuid v5) e as funções monetárias (mathjs) do dist devolvem os mesmos valores da 0.17.1 publicada.

Decisões

Decisão	Escolha	Motivo
Faixa do peer do express	Só ^5.0.0 (opção B do ticket)	O framework passa a mirar uma versão só do express, sem manter compatibilidade de tipos e comportamento com o 4. O express 5 é a linha ativa, e o pact e os serviços novos já o exigem.
Escopo das atualizações	Só dependências que continuam funcionando no Node 20	A google-auth-library 11 exige Node 22, e o uuid 12+ é só ESM (no build CJS só carrega a partir do Node 20.19). Por isso ficam na 9 e na 11. @dbos-inc/dbos-sdk 5 e @prisma/client 7 também ficam fora, porque pedem mudança de código (API de filas do DBOS; tipos do Prisma só a partir do client gerado). As ferramentas de dev não afetam os consumidores.
Versão	1.0.0	É uma breaking change, então sobe o major. Quem está em ^0.x não pega a mudança sem querer.

Depois do merge

Publicar a 1.0.0 e seguir o TIM-3729 no tim-network-adapter.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-13T22:06:09.821083Z	6d1f5a9	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.