Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

refactor: share one headless-Chrome helper between check-render and build-og-card

Abierto
  • ¿Algo no está bien?
#171 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
72/100
Tipo de issue
Refactorización
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
javascript, node.js
Área
tooling

Línea de trabajo

Lee scripts/check-render.mjs y scripts/build-og-card.mjs; después compara su código de descubrimiento, lanzamiento, apagado de Chrome y del cliente CDP. Extrae las partes compartidas a scripts/chrome.mjs, dejando en su lugar el comportamiento específico del renderizado y las decisiones de PAGE_TIMEOUT_MS de los llamadores. Ejecuta npm run check-render y npm run og-card; se considera terminado cuando los fallos de renderizado siguen siendo idénticos y la card sigue siendo comparable byte a byte.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

ci infra

Branch off master and PR into master, not main. This is the v1 site.

scripts/build-og-card.mjs (#130) needs headless Chrome for exactly the same reasons scripts/check-render.mjs does, and it now carries its own copy of the same four pieces of plumbing:

  • findChrome() — the CHROME_PATH override and the per-platform install locations
  • launchChrome() — the flag set, and scraping the DevTools URL out of stderr
  • stopChrome() — waiting for the exit rather than the signal, because Windows keeps the user-data-dir locked until Chrome has gone
  • connect() / withTimeout() — the minimal CDP client over one browser-level socket

The card builder's copy is the smaller of the two: it drives one page, so it drops the event waitFor and the per-target session bookkeeping check-render needs. Nothing about the Chrome handling itself differs.

This is the shape #162 was about. There, check-canonicals and check-render had a static.yml allowlist parser each, and they had already drifted in a way that mattered: the render check read only the first cp ... _site/, so a page added in a later cp deployed but was never rendered. One parser in scripts/static-allowlist.mjs fixed it. The same argument applies here before these two copies drift — a fix to Chrome discovery, or a new flag needed for a future Chrome, currently has to be made twice, and only one of the two runs in CI, so the other can rot unnoticed.

Not urgent: the copies are identical today, and build-og-card.mjs is a manual tool run rarely rather than a check. Filed so it is a decision rather than an accident.

Proposal

Extract the shared parts into scripts/chrome.mjs, alongside scripts/static-allowlist.mjs, and have both scripts import it. check-render.mjs keeps whatever is genuinely specific to rendering every page (the viewport list, the is-loading and image-ratio measurement, the page loop).

Worth deciding as part of it: whether PAGE_TIMEOUT_MS belongs to the module or stays per-caller, since the two have no reason to agree.

Acceptance criteria

  • One copy of Chrome discovery, launch, shutdown and the CDP client
  • npm run check-render behaves identically — same failures on a broken image, a distorted aspect ratio and a stuck is-loading
  • npm run og-card still produces a byte-comparable card
  • Neither script reaches into the other

Refs #130, #162

Lenguaje dominante
HTML
Estrellas
0
Forks
0
Merge medio
10 h 2 min
PR fusionados (30 d)
41

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

  • Sin Dockerfile ni archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de laywill/laywill.github.io

Todos los issues de laywill/laywill.github.io

Issues similares

Más issues de DevTools

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.