Verificadores

Un solo comando con 18 comprobaciones, y por que no se para en el primer fallo.

La plantilla trae dieciocho comprobaciones automaticas bajo un solo comando. Es la misma barrera con la que esta construida ApisKit, no una version rebajada para el comprador.

npm run verify:all       # mientras trabajas
npm run verify:release   # antes de publicar

Los dos ejecutan la misma lista. verify:release es verify:all --publicar y ademas corre las comprobaciones marcadas como "solo al publicar", que hoy son las pruebas de navegador, las unicas que levantan un servidor. Todo lo demas corre en las dos, asi que el comando rapido nunca es por accidente un comando mas debil.

Por que un solo comando

Porque los verificadores sueltos se olvidan. Si hay siete comandos, se ejecutan tres. La lista esta en un unico catalogo, en scripts/verify-all.ts, y anadir una comprobacion es anadir una entrada a ese array. Por construccion, no puede existir un verificador fuera de la puerta.

Tres cosas que lo hacen fiable

No se para en el primer fallo. Todas las comprobaciones se ejecutan y al final tienes un parte con el estado de cada una. Ves de una pasada todo lo que hay que arreglar, en vez de descubrirlo de uno en uno.

Nada se da por bueno sin ejecutarse. Una comprobacion que no puede correr (faltan credenciales, esta aplazada al publicar) se informa como OMITIDA con su motivo, nunca como correcta. El resumen las cuenta aparte y dice en voz alta que no estan aprobadas.

Algunas miran tus datos, no tu codigo. Una comprobacion de forma no puede ver que una pagina publicada se quedo sin traducir, ni que dos se pelean por la misma direccion. Eso se audita contra la base de datos de verdad.

Que se comprueba

Comprobacion	Que garantiza
Calidad de codigo	Nada de TODO, FIXME, `any`, simulaciones ni codigo sin efecto.
Manejo de errores	Ningun error silenciado ni `catch` vacio.
Seguridad en ejecucion	Sin accesos que revienten al ejecutar.
Consistencia de tipos	Los tipos del dominio no se contradicen entre capas.
Idiomas	Espanol e ingles simetricos, y toda clave usada existe.
Colores del tema	Ningun color a pelo: todo por tokens.
Compilacion	El sitio construye entero.
Tipado	Compila sin errores de tipos, pruebas incluidas.
Estilo	Sin avisos ni errores de lint.
Duplicados	Sin bloques copiados y pegados.
Pruebas unitarias	La logica aislada se comporta como debe.
Vulnerabilidades	Ninguna dependencia con vulnerabilidad conocida.
Indices de administracion	Firestore tiene los indices que el panel necesita.
Indices de soporte	Los que necesita el soporte.
Documentacion publicada	Ninguna pagina rota, huerfana ni sin traducir.
Indices de documentacion	Los que necesita la documentacion.
Pruebas de integracion	Las rutas responden bien y no filtran errores internos.
Pruebas de navegador	Los recorridos completos funcionan de verdad.

Los tres verificadores de indices no se fian del fichero: declarar un indice no demuestra que exista. Lanzan las consultas reales contra tu proyecto y te dicen cuales rechaza la base de datos.

Lo que necesita algo de fuera

Comprobacion	Necesita
Indices y documentacion publicada	Credenciales de Firebase en `.env.local`
Pruebas de navegador	`npm run verify:release`

Dos ordenes que conviene respetar

Si algun dia reordenas el catalogo, conserva estas dos:

La compilacion va antes que el chequeo de tipos. Un tipo de ruta generado y viejo hace fallar a tsc por un motivo que no es tuyo.
Ninguna comprobacion llama a process.exit() a mitad, usa process.exitCode. Asi un fallo no corta el parte.

Un verificador que nunca ha fallado no demuestra nada

Puede estar mirando al reves. Los verificadores de esta plantilla se prueban metiendoles el fallo a proposito y comprobando que se ponen en rojo.

Vale la pena que hagas lo mismo con los tuyos. Es la unica forma de saber que una prueba en verde significa algo.

Antes de publicar

npm run verify:release && npm run licenses

En verde los dos, la barrera esta cumplida. Lee el parte, no solo el codigo de salida: una ejecucion puede acabar en verde y aun asi listar comprobaciones como OMITIDA, y una comprobacion omitida no es una comprobacion aprobada.