Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#187 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
65/100
issue の種類
リファクタリング
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
html, vscode
領域
developer-experience, tooling

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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

主要言語
HTML
スター
0
フォーク
0
平均マージ
9時間 52分
マージ済み PR（30日）
59

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

  • Dockerfile・Docker Compose ファイルなし
  • プルリクエストのテンプレートなし
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

laywill/laywill.github.io のほかの issue

laywill/laywill.github.io の issue をすべて見る

似ている issue

DevTools の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。