Publicar una versión

Solo para mantenedores. Esta página trata de publicar una nueva versión de becwright en npm y PyPI. Si solo usas becwright, nunca la necesitas — instálalo con los comandos de la Introducción.

becwright se distribuye por tres canales desde un único release de GitHub:

• PyPI — el paquete de Python (pip / pipx).
• npm — un paquete lanzador (becwright) más cinco paquetes por plataforma con os/cpu (@becwright/<target>), cada uno con un binario precompilado, para que quien no usa Python pueda instalarlo.

Configuración inicial (una vez)

• PyPI: vía Trusted Publishing (OIDC), sin token almacenado. Ver el job pypi en .github/workflows/release.yml.
• npm:
  • Crear el scope/org @becwright en npm y asegurar que la cuenta también sea dueña del nombre sin scope becwright.
  • Agregar un token de acceso de automatización como secreto del repositorio NPM_TOKEN.

Sacar una versión

1. Subir la versión en pyproject.toml (las versiones de npm se derivan del tag de git al publicar, no hace falta editarlas).
2. Commit y crear un release de GitHub con tag vX.Y.Z (debe coincidir con pyproject.toml).
3. Publicar el release dispara release.yml, que:
   • construye y prueba el binario en todas las plataformas (macOS como binario universal2),
   • stagea cada binario en su paquete @becwright/<target> (npm/stage.mjs),
   • fija la versión de cada paquete npm desde el tag (npm/set-version.mjs),
   • publica primero los paquetes de plataforma y luego el lanzador,
   • construye y publica el paquete de Python en PyPI.

Compatibilidad (desde 1.0.0)

Una vez que salga 1.0.0, el contrato público (el esquema de rules.yaml, el formato de bundle .bec.yaml, los nombres y flags de los checks integrados, los comandos y códigos de salida de la CLI, la forma de check --json y las firmas de las herramientas MCP) sigue una política de deprecación con un minor de aviso:

• Nunca quitar ni romper nada del contrato dentro de un minor o un patch.
• Para retirar algo, marcarlo deprecado en un minor (sigue funcionando y avisa), y quitarlo solo en el siguiente major.
• Un cambio que rompería un archivo de reglas, bundle o script de check de 1.x va en un bump mayor, no en un minor.

Ver la doc de estabilidad y versionado para la declaración de cara al usuario.

Notas

• Los paquetes de plataforma se publican antes que el lanzador para que sus optionalDependencies resuelvan de inmediato.
• npm publish no es idempotente: re-ejecutar una versión ya publicada falla. Subí la versión para volver a publicar.
• Para probar los binarios sin publicar, ejecuta el workflow Build binaries manualmente (workflow_dispatch).