hugo-site/config.toml is dead config: Hugo loads hugo.toml and ignores it

[sanity]

Problem

hugo-site/ contains both hugo.toml and config.toml, with different, non-overlapping content. Hugo ≥0.110 prefers hugo.toml and ignores a root config.toml entirely, so everything in config.toml is silently inert.

config.toml currently holds only settings that are therefore having no effect:

• [[module.mounts]] for static and static/wasm
• [server.headers] setting Content-Type: application/wasm for /wasm/**
• [mediaTypes."application/wasm"]
• [outputFormats.WASM]

Evidence

Confirmed empirically against hugo config (Hugo 0.154.5), not inferred:

• [outputFormats.WASM], defined only in config.toml, is absent from the effective config.
• The static/wasm -> static/wasm mount is absent; hugo config shows only Hugo's default mounts (content, data, layouts, …).
• The [[server.headers]] block for /wasm/** is absent from the effective [server].

Note application/wasm does appear in the effective config's mediaTypes — but that is Hugo's built-in, not the one declared here. Checking for it is a false positive; check [outputFormats.WASM] instead.

Impact

Low today, but it's a trap rather than a bug:

• hugo server won't stamp Content-Type: application/wasm on dev requests. Production is unaffected (GitHub Pages sets its own headers).
• static/ is mounted by default anyway, so the explicit mounts are redundant.

The real cost is that the next person to edit config.toml will get no effect and no warning. Two independent reviewers hit this file during an unrelated docs review and both had to stop and determine which config Hugo actually reads.

Suggested fix

Either delete config.toml, or merge its blocks into hugo.toml if any are actually wanted. Deleting is probably right for the mounts (redundant with defaults) and the mediaType (Hugo has it built in); the dev-server header and the custom output format are the two worth a moment's thought before dropping.

Worth verifying the WASM/ghostkey pages still build and serve correctly either way, since that's the surface these settings were aimed at.

Found while working on #110. Not fixed there to keep a docs copy change from touching the build config.

[AI-assisted - Claude]

[sanity]

Issue Priority Assessment

Generated: 2026-08-22T16:44:37.790316142+00:00
Issue hash: 180bfa8f

Value Assessment

Both files still exist, unchanged from the issue's description — this is still fully relevant, not fixed.

Relevance: Confirmed live. hugo-site/config.toml and hugo-site/hugo.toml both exist right now with the exact non-overlapping content described. Since Hugo prefers hugo.toml when both are present, config.toml's mounts, wasm media type/output format, and dev-server header are dead weight. Nothing in recent history (last touch on hugo.toml was Jul 27, config.toml Dec '25) suggests this was addressed.

User impact: Minimal and indirect — it doesn't affect production (GitHub Pages sets its own headers) and static/ is mounted by default anyway, so end users see nothing. The impact is entirely on contributors: anyone editing Hugo config gets silent no-ops, as already happened twice per the issue (during #110's review).

Strategic alignment: Low-stakes housekeeping, not roadmap-advancing. It's a small correctness/cleanliness item for the site's build config, unrelated to Ghost Key or core product goals.

Blocking factor: None — nothing depends on this being fixed today. It's a trap for future editors, not a current blocker.

Urgency: Low. It's a "fix whenever convenient" cleanup — cheap to resolve (delete redundant blocks, decide on the two Hugo-server-only settings, verify WASM pages still build) but not time-sensitive since production is unaffected.

Cost Assessment

This is still accurate — both files exist exactly as described, unchanged since the issue was filed.

Cost assessment

This is a very low-cost, low-risk cleanup. The issue is fully actionable as-is: config.toml still contains exactly the four dead blocks described (redundant static/static/wasm mounts, a /wasm/** Content-Type header, a custom application/wasm mediaType, and the WASM outputFormat), and hugo.toml remains the file Hugo actually loads (confirmed it has no overlapping keys, so there's no merge conflict to resolve). The fix is a single-file change: either delete config.toml outright, or move the header/outputFormat blocks into hugo.toml if they're deemed worth keeping. No other files, modules, or subsystems are touched — this doesn't intersect any of the WASM build/publish pipeline code, just Hugo's own config discovery.

Complexity is minimal — this is data deletion/merging in TOML, not logic. The only judgment call is whether the dev-server WASM Content-Type header and the custom WASM outputFormat are worth preserving (the issue author already leans toward dropping the mounts/mediaType as redundant with Hugo defaults, and thinks the header/outputFormat merit "a moment's thought"). No external dependencies: no signups, credentials, or third-party coordination — purely a local repo edit.

Risk is low but not zero: GitHub Pages sets its own headers in production, so deleting the [server.headers] block has no prod impact, but if the WASM output format was silently relied upon by wasm-bindgen tooling or CI in some way not caught by hugo config, that would be a regression; grepping for outputFormats.WASM usage elsewhere in the codebase before deleting would be prudent. Testing effort is small: run hugo server -D, load the ghostkey/wasm pages, verify hugo config output for the merged/removed keys, and run cargo make build-site once to confirm no build break. Overall this is a same-session, single-PR fix — well under an hour of work including verification.

---

Generated by issue-prioritizer