Descrição

Causa raiz: o services/date.js só estende os plugins utc e timezone do dayjs. Sem o plugin customParseFormat, o dayjs ignora o formato passado em dayjs(valor, formato). Por isso o toISOString(igpmIndex.data, 'DD/MM/YYYY') do services/indices/igpm.js cai no new Date('01/06/2026'), que lê a data como MM/DD (6 de janeiro). Como o BCB sempre manda o IGP-M no dia 01, toda data sai em janeiro, com o dia igual ao mês real.

Em produção hoje:

• BCB (bcdata.sgs.189/dados/ultimos/3): {"data":"01/06/2026","valor":"-0.50"}
• BrasilAPI (/api/indices/igpm/v1/ultimos?limit=3): {"value":-0.5,"date":"2026-01-06T00:00:00.000Z"}

Correção: carregar o plugin customParseFormat no services/date.js (2 linhas). Vale para os três endpoints: /indices/igpm/v1, /ultimos e /intervalo. Com a correção, o mesmo registro volta como 2026-06-01.

Teste: tests/services/indices/igpm.test.js mocka o axios com um registro do BCB 01/06/2026 e verifica que a data retornada é 1 de junho. Falha antes da correção (expected +0 to be 5, ou seja, janeiro) e passa depois. Não depende da rede nem do BCB. O tests/services/date.test.js cobre o modo strict do parseToDate usado no /intervalo (ver Notas Adicionais).

Tipo de Mudança

• Correção de bug (mudança que corrige um problema)
• Nova funcionalidade (mudança que adiciona funcionalidade)
• Breaking change (correção ou funcionalidade que causa quebra de compatibilidade)
• Documentação (mudanças apenas em documentação)
• Refatoração (mudança que não corrige bug nem adiciona funcionalidade)
• Performance (mudança que melhora performance)
• Testes (adiciona ou corrige testes)
• Configuração (mudanças em configuração ou build)

Checklist de Compatibilidade (CRÍTICO)

• Não remove campos de respostas de API existentes
• Não renomeia campos de respostas de API existentes
• Não muda tipos de dados de campos existentes (string para number, etc.)
• Não muda o formato de URLs de endpoints existentes
• Não muda códigos de status HTTP de endpoints existentes (exceto datas fora do formato documentado ou inexistentes no /intervalo, ver Notas Adicionais)
• Se fez mudanças incompatíveis, criei uma nova versão (v2, v3, etc.)

Checklist de Documentação

• Atualizei ou criei documentação OpenAPI em /pages/docs/doc/
• Documentação inclui exemplos de requisição e resposta
• Documentação está em português
• Atualizei README.md se necessário
• N/A - Mudanças não requerem documentação

Checklist de Testes

• Criei ou atualizei testes E2E
• Todos os testes passam localmente (npm test) (rodei os de IGP-M, câmbio e os unitários; os demais dependem de APIs externas e não foram tocados)
• Teste de CORS funciona corretamente
• Testei casos de erro (404, 400, 500, etc.)
• Testei casos de sucesso
• N/A - Mudanças não requerem testes

Checklist de Código

• Código segue os padrões do projeto (ESLint + Prettier) (sem apontamentos nos arquivos alterados)
• Executei npm run fix antes de commitar
• Não adicionei dependências desnecessárias ou pesadas
• Código não expõe credenciais ou informações sensíveis
• Validei todos os inputs de usuário
• Tratei erros apropriadamente
• Usei Conventional Commits

Checklist de Performance e Custos

• Não adicionei processamento pesado que aumenta custos
• Usei cache quando apropriado
• Minimizei chamadas a APIs externas
• Considerei impacto em rate limits de APIs externas
• Testei performance em casos de alto volume

Como Testar

1. Com o npm run dev rodando (o setup global dos testes espera o servidor em localhost:3000): NODE_ENV=test npx vitest run tests/services/indices/igpm.test.js tests/services/date.test.js
2. Sem a mudança no services/date.js, o teste falha com expected +0 to be 5; com a mudança, passa.
3. curl "http://localhost:3000/api/indices/igpm/v1/ultimos?limit=3" agora retorna 2026-06-01, 2026-07-01 e 2026-08-01, iguais ao BCB. Os testes E2E existentes em tests/indices/igpm.test.js e tests/cambio-v1.test.js continuam passando.

Screenshots (se aplicável)

N/A

Issues Relacionadas

Nenhuma.

Notas Adicionais

O parseToDate(valor, 'YYYY-MM-DD') e o modo strict do validateDateComponents também passam a funcionar como estão escritos. No câmbio nada muda, porque a data já é validada por regex antes. No /intervalo, datas válidas no formato YYYY-MM-DD têm o mesmo resultado de antes.

O que muda no /indices/igpm/v1/intervalo, que agora valida as datas em modo strict no formato YYYY-MM-DD:

• Sem initial_date ou sem final_date, o parâmetro ausente era tratado como a data atual (só initial_date=2026-01-01 retornava 200 com tudo até hoje). Agora retorna 400 com "Intervalo de datas inválido, informe um intervalo correto", que é o que a documentação OpenAPI (required: true) e os testes E2E existentes já esperam.
• Datas fora do formato, como 2026-1-1 ou 20260101, eram aceitas e agora também retornam 400.
• O parseToDate ganhou um terceiro parâmetro opcional strict (padrão false, então o câmbio não muda) e o /intervalo passa true. Assim, qualquer entrada fora do formato YYYY-MM-DD, incluindo texto sobrando no fim como 2026-01-01abc, continua retornando 400. Uma data inexistente como 2026-02-30, que antes era aceita e consultada no BCB como 02/03/2026, também passa a retornar 400. O tests/services/date.test.js cobre esses dois casos: falha sem o modo strict e passa com ele.