Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#187 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
65/100
Type d'issue
Refactorisation
Clarté
Clairement spécifiée
Activité
Active
Stack technique
html, vscode
Domaine
developer-experience, tooling

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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).

Langage dominant
HTML
Étoiles
0
Forks
0
Merge moyen
9 h 52 min
PR mergées (30 j)
59

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

  • Aucun Dockerfile ni fichier Docker Compose
  • Aucun modèle de pull request
  • Aucun guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de laywill/laywill.github.io

Toutes les issues de laywill/laywill.github.io

Issues similaires

Plus d'issues DevTools

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.