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

VSCode format-on-save reflows the shared footer on every page it touches

Abierto
  • ¿Algo no está bien?
#187 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
65/100
Tipo de issue
Refactorización
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
html, vscode
Área
developer-experience, tooling

Línea de trabajo

First, examine the .vscode/settings.json file to understand the current format-on-save configuration. Then, run the provided js-beautify command on a sample HTML file (like coffee.html) to see the changes. The goal is to normalize all footers to be identical, then apply the formatter. After making changes, run pre-commit checks and verify the MegaLinter output to ensure no regressions. The final state should have all shared footer regions byte-identical across pages.

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

Descripción

infra

.vscode/settings.json sets "editor.formatOnSave": true, and VSCode's built-in HTML formatter reformats the whole document, not just the region being edited. So editing any page's copy also rewrites its footer, its social links and its <!-- Scripts --> block: exactly the regions CLAUDE.md requires to stay byte-identical across every page.

It happened in #182. A copy pass over coffee.html reflowed the footer's <li> elements, giving that region a third variant. It was spotted in review and restored by hand before committing, but only because someone was looking.

What the formatter is

VSCode's built-in HTML formatter is js-beautify. Its output is reproducible outside the editor:

npx js-beautify@1 --type html --wrap-line-length 120 --indent-size 2 -f coffee.html

That reproduces VSCode's footer byte for byte. Prettier does not: at --print-width 120 it rewrites about 626 lines of index.html, so whatever shaped this tree, it was not Prettier.

The tree is close to js-beautify's shape already. Running it over every page changes about 460 lines in total, roughly 28 a page, and most of that is the footer.

The catch that decides the approach

js-beautify is idempotent but not convergent. It preserves existing newlines, so it keeps whatever line breaks a file already has rather than imposing its own. Running it a second time changes nothing, but running it over pages whose footers already differ leaves them differing: four distinct footer shapes survive the pass.

So "get VSCode to touch all the footers so they agree" does not work by formatting alone. The footers have to be made identical first; formatting then keeps them that way.

Options

A. Turn format-on-save off for HTML. One line in .vscode/settings.json:

"[html]": { "editor.tabSize": 2, "editor.formatOnSave": false }

No diff, no risk, and manual edits stay exactly as typed. It binds only whoever has this repo's settings, and it means hand-formatting new markup.

B. Normalise once, then let the formatter hold the line. Paste one canonical footer into every page, run the formatter over the tree at fixed settings, commit the result. After that, saving an untouched page is a no-op, and saving an edited page reproduces the canonical footer rather than a new variant. One PR of about 460 lines, and it clears the drift in #185 at the same time.

C. Pin the formatter's settings, whichever of A or B is chosen:

"html.format.wrapLineLength": 120,
"html.format.indentInnerHtml": false

Today those are defaults, so a VSCode version that changes a default silently changes the shape of the tree. Pinning them costs nothing.

Recommendation: B and C, with #185's check as the backstop. An editor setting binds one person on one machine; a CI check that the shared regions are byte-identical is what actually makes this survive. B without that check just resets the clock.

Hazards for whoever does B

  • Reformatting HTML moves whitespace between inline elements, and whitespace between inline elements is rendered. render.yml will not catch a stray or missing space. The credit badges are the place to look first: their <span>s sit directly against text with no space in between, and coffee.html has seven of them.
  • The formatter's output has to keep MegaLinter green. djlint already reports findings locally that MegaLinter never surfaces (#109), so run pre-commit run --all-files and check the MegaLinter run on the PR rather than assuming.
  • The <!-- Scripts --> block and the is-loading gate must come through unchanged: same scripts, same order, same onerror attributes.

Related: #185 (the check), #182 (where this surfaced), #109 (djlint).

Lenguaje dominante
HTML
Estrellas
0
Forks
0
Merge medio
9 h 52 min
PR fusionados (30 d)
59

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.