becwright vs pre-commit

becwright y pre-commit se encuentran en el mismo lugar — el hook pre-commit de git — pero son herramientas de tipo distinto. pre-commit es un framework que instala y gestiona hooks escritos por otros: linters, formatters y escáneres de un enorme ecosistema comunitario, orquestados desde .pre-commit-config.yaml. becwright es un motor de constraints que trae sus propios checks deterministas y ata cada regla a la intención que hay detrás. El veredicto honesto: se complementan, y muchos repos deberían correr ambos.

TL;DR — pre-commit te da un ecosistema gigante de hooks de terceros, pero no trae ningún check propio y necesita un intérprete de Python para funcionar. becwright trae checks que funcionan desde el primer minuto (secretos hardcodeados, tokens en logs, restos de depuración, un regex genérico forbid), no necesita Python gracias a un binario autocontenido de npm, y ata cada regla a su porqué. Quédate con pre-commit para linters y formatters; agrega becwright para las constraints que nunca deben romperse.

¿Qué es pre-commit?

pre-commit es un framework multi-lenguaje para gestionar hooks de git. Listas repositorios de hooks y sus ids en .pre-commit-config.yaml; el framework los clona, construye entornos aislados para cada uno (Python, Node, Ruby, Go y más), fija versiones y ejecuta los hooks sobre los archivos cambiados en cada commit. pre-commit autoupdate actualiza las versiones, y pre-commit.ci corre la misma configuración en CI.

Su ecosistema es, por mucho, el más grande entre las herramientas de hooks: hay hooks comunitarios para casi cualquier linter, formatter o escáner conocido — black, ruff, mirrors de eslint y prettier, shellcheck, terraform fmt y cientos más. Si tu objetivo es «correr las herramientas que ya usamos, en el commit, con versiones fijadas», pre-commit es la respuesta estándar y becwright no intenta competir con eso.

¿Qué hace becwright que pre-commit no hace?

Cuatro cosas, y definen cuándo se gana un lugar junto a pre-commit:

1. Checks incluidos. pre-commit no trae ningún check — cada comportamiento viene de un repo de hooks externo que tú eliges, auditas y fijas. becwright funciona desde que ejecutas becwright init: sus checks integrados atrapan secretos hardcodeados, tokens en llamadas de log, eval()/exec(), breakpoints olvidados, y cualquier cosa que puedas expresar como regex con el check genérico forbid.
2. Cada regla está atada a su intención. En .pre-commit-config.yaml, un hook es una URL de repo y un id; la razón por la que existe vive en una wiki o en la cabeza de alguien. Una regla de becwright lleva intent y why_it_matters en .bec/rules.yaml y los imprime cuando falla — exactamente lo que un agente de IA (o alguien nuevo en el equipo) necesita para arreglar la violación en vez de borrar la regla. Mira el formato completo en Escribir checks.
3. Sin necesidad de Python. El framework pre-commit es en sí una aplicación de Python. Los paquetes de npm y pnpm de becwright traen un binario autocontenido para linux-x64, linux-arm64, darwin-x64, darwin-arm64 y win32-x64 (pipx sigue disponible para todo lo demás).
4. Legible por máquina y portable. becwright check --json devuelve pasa/no-pasa estructurado con la intención de cada regla, un servidor MCP expone check y list_checks a cualquier agente con MCP, y becwright export/import mueve una regla entre repos como un único bundle autocontenido .bec.yaml.

becwright vs pre-commit: lado a lado

Aspecto	pre-commit	becwright
Qué es	Gestor / framework de hooks	Motor de constraints con checks propios
Runtime necesario	Intérprete de Python	Ninguno — binario autocontenido vía npm/pnpm (pipx opcional)
¿Trae checks integrados?	No — los hooks vienen de repos externos	Sí — secretos, tokens en logs, eval, restos de debug, forbid genérico
Vínculo regla ↔ intención	No — la config lista repos e ids de hooks	Sí — intent y why_it_matters en cada regla
Bundles de reglas portables	Repos de hooks, fijados por proyecto	Un solo archivo .bec.yaml vía export / import
Salida para agentes de IA	Texto plano	check --json + servidor MCP + plugin de Claude Code
Tamaño del ecosistema	Enorme — cientos de hooks comunitarios	Catálogo becs/ pequeño y en crecimiento
Cómo se salta	git commit --no-verify lo omite	git commit --no-verify también lo omite

Dos notas honestas sobre la tabla. Primera: la fila del ecosistema es decisiva cuando tu necesidad es «correr black, ruff y eslint en el commit» — ese es el terreno de pre-commit. Segunda: ninguna de las dos herramientas sobrevive a --no-verify; ambas son hooks locales, así que ambas se combinan naturalmente con una re-ejecución en CI (becwright check --all funciona bien ahí).

¿Cuándo basta con pre-commit solo?

• Todo lo que quieres imponer es formateo y linting ya cubiertos por hooks comunitarios existentes.
• Tu equipo tiene Python en todas partes y una .pre-commit-config.yaml madura y fijada con la que nadie pelea.
• Tus reglas no necesitan cargar contexto — no hay agentes de IA regenerando código, ni arqueología de «¿por qué existe esta regla?».

También es justo decir que el escaneo de secretos puede vivir dentro de pre-commit — tanto gitleaks como detect-secrets publican hooks de pre-commit. Lo que esa configuración no te da son checks que funcionan sin configurar nada, reglas atadas a la decisión que las creó, ni una superficie JSON/MCP que un agente pueda consumir.

Correr becwright junto a pre-commit

Si pre-commit ya es dueño de tus hooks, no pelees con él — registra becwright como hook local para que ambos corran en cada commit:

repos:
  - repo: local
    hooks:
      - id: becwright
        name: becwright check
        entry: becwright check
        language: system
        pass_filenames: false

language: system usa el becwright ya instalado en tu proyecto (dependencia de desarrollo de npm o pipx). pass_filenames: false importa: becwright le pide a git los archivos en stage por su cuenta, así que pre-commit no debe añadir su propia lista de archivos. Cuando una regla blocking falla, becwright check sale con código 1 y pre-commit rechaza el commit como con cualquier otro hook que falla.

Si no usas pre-commit, no necesitas el framework para nada: becwright install (o becwright init, que además genera las reglas) instala un hook nativo de git directamente.

¿Cómo bloqueas secretos en los commits sin Python?

Esta es la pregunta que separa a las dos herramientas con más claridad. Con pre-commit, la respuesta empieza por «instala Python, luego el framework, luego elige un hook de secretos». Con becwright son tres comandos:

npm install --save-dev becwright   # binario autocontenido, sin Python
npx becwright init                 # genera .bec/rules.yaml + instala el hook
npx becwright check --all          # mira el estado actual de todo el repo

Desde ese momento, el check integrado hardcoded_secrets bloquea claves AWS, claves privadas y literales password = "..." en cada commit. Para detección de secretos más profunda — análisis de entropía y escaneo de todo el historial — mira becwright vs gitleaks.

¿Cuál deberías elegir?

Normalmente, ambos. pre-commit orquesta las herramientas en las que ya confías; becwright es la capa de constraints deterministas y atadas a su intención por encima — las reglas que un agente de IA no puede esquivar con labia, porque corren sobre el código real y devuelven pasa/no-pasa. Si tu proyecto es JavaScript y usas husky en vez de pre-commit, aplica la misma lógica — mira becwright vs husky. Para probarlo en tres comandos, empieza por el quickstart; para que tu agente lo maneje por ti, mira la integración con Claude Code.

FAQ

¿becwright reemplaza a pre-commit?

No. pre-commit es un framework que instala y ejecuta hooks de un gran ecosistema comunitario; becwright es un motor de constraints que trae sus propios checks deterministas y ata cada regla a la intención que la creó. Un equipo que ya usa pre-commit para linters y formatters puede agregar becwright como hook local y mantener ambas herramientas corriendo en cada commit.

¿Puede becwright correr como hook dentro de pre-commit?

Sí. Declara un hook repo: local cuyo entry sea becwright check, con language: system y pass_filenames: false. becwright le pide a git los archivos en stage por su cuenta, ejecuta cada regla de .bec/rules.yaml y devuelve código de salida 1 cuando falla una regla blocking, con lo que pre-commit rechaza el commit igual que con cualquier otro hook que falla.

¿Cómo bloqueo secretos en los commits sin instalar Python?

Instala becwright desde npm o pnpm: el paquete trae un binario autocontenido para linux-x64, linux-arm64, darwin-x64, darwin-arm64 y win32-x64, así que no necesitas un intérprete de Python. Ejecuta becwright init para generar .bec/rules.yaml e instalar el hook de git; el check integrado hardcoded_secrets bloquea claves AWS, claves privadas y literales de password en cada commit.