mirror of
https://github.com/melgarafael/DeskcommCRM.git
synced 2026-10-02 01:28:34 +08:00
Rafael MelgaçoandClaude Opus 5
d6ae200192
A imagem Docker do self-host quebrou na `main` e nenhum check obrigatório viu.
## O defeito
`.dockerignore` deixa `tests/` fora da imagem, de propósito. Mas há 7 arquivos
`*.test.ts` COLOCADOS (dentro de `app/`, `components/`, `lib/`) que importam
`@/tests/helpers/*` e `@/tests/support/*`. A partir do next 16.3, o `next build`
typecheca esses colocados — e dentro da imagem os módulos não existem.
Causa estabelecida com uma variável só, mesma árvore, sem `tests/`:
next 16.2.12 → build exit 0
next 16.3.0 → build exit 1, 7× TS2307 "Cannot find module '@/tests/...'"
A primeira tentativa de conserto foi manter `tests/helpers` no contexto. É
remendo: passa do TS2307 e cai no TS2339 do jest-dom, cuja augmentação de tipos
também mora em `tests/`. Preservar teste dentro da imagem é perseguir o
sintoma — o build de produção não tem por que compilar teste.
## O conserto
`tsconfig.json` (o que o `next build` usa) exclui `**/*.test.ts(x)` e `tests/**`.
`tsconfig.typecheck.json` reinclui tudo, e é para ele que o `pnpm typecheck`
aponta. A imagem fica hermética sem perder um arquivo de cobertura de tipos.
Medido:
build sem tests/ → exit 0, 0 erros TS
erro de tipo em tests/unit/rbac-matrix.test.ts → typecheck exit 2 (TS2322)
erro de tipo em app/.../version/route.test.ts → typecheck exit 2 (TS2322)
ambos restaurados → typecheck exit 0
O segundo e o terceiro são o que impede este commit de ser "apagar a guarda":
os dois lados da fronteira continuam vigiados.
## A catraca
`publish-image.yml` rodava só em push na `main`, em tag e em release — nunca em
`pull_request`. Nenhum PR conseguia revelar que quebrava a imagem, e foi por
isso que um bump passou pelos quatro obrigatórios e derrubou o artefato que o
cliente instala. Agora o PR CONSTRÓI a imagem (o gate) e não publica
(`push: false` em PR, login pulado) — fork não tem escrita no GHCR, e publicar
código não revisado seria pior que não gatear.
Falta um passo que é do mantenedor: incluir este check na branch protection.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01L2dRaL9UCKhhwJLUbFTsHW
29 lines
1.1 KiB
JSON
29 lines
1.1 KiB
JSON
{
|
|
// O `pnpm typecheck` do repo — cobre TUDO, inclusive os testes.
|
|
//
|
|
// Por que existe um segundo tsconfig: desde o next 16.3 o `next build`
|
|
// typecheca os `*.test.ts` COLOCADOS (os que moram em app/, components/,
|
|
// lib/ ao lado do código que testam). Isso amarra o build de produção ao
|
|
// toolchain de teste — e o `.dockerignore` deixa `tests/` fora da imagem,
|
|
// então a imagem do self-host passou a falhar com TS2307/TS2339 enquanto
|
|
// `verify`, `build-and-size`, `invariants` e `e2e` seguiam verdes.
|
|
//
|
|
// Medido, mesma árvore, sem `tests/`: next 16.2.12 constrói (exit 0);
|
|
// next 16.3.0 não (exit 1). Excluir teste do tsconfig do BUILD resolve na
|
|
// raiz — o build de produção não tem por que compilar teste.
|
|
//
|
|
// A cobertura de tipos NÃO cai: é este arquivo que o `pnpm typecheck` usa,
|
|
// e ele reinclui o que o outro exclui.
|
|
"extends": "./tsconfig.json",
|
|
"include": [
|
|
"next-env.d.ts",
|
|
"**/*.ts",
|
|
"**/*.tsx",
|
|
".next/types/**/*.ts",
|
|
".next/dev/types/**/*.ts",
|
|
"tests/**/*.ts",
|
|
"tests/**/*.tsx"
|
|
],
|
|
"exclude": ["node_modules", ".next", "dist", "scripts/**"]
|
|
}
|