Support .htm extension alongside .html

[yolo-sam]

Closes #9.

Summary

• Add .htm as a routing alias for .html. Both extensions now open in the html-docs view, get embed support, and resolve from internal links.
• Introduce a single HTML_EXTENSIONS constant + isHtmlExtension guard so the five existing touch points reference one source of truth.
• .mhtml is explicitly not supported (MIME archive format, separate feature — see updated issue body).

Diff size

main.ts +9 lines, test/test.sh ±2 lines. Build clean, lint clean. Bundle size: 7805 → 7805 bytes (rounding).

Test plan

• npm run build succeeds (TypeScript + esbuild).
• npm run lint clean.
• Reviewer: drop dist/html-docs/main.js into vault, run npm test. New assertions: .htm routes to html-docs view, .htm embed registered. Existing .html and embed/canvas assertions unchanged.
• Reviewer: rename a vault file from foo.html to foo.htm, open it — same rendering, same embed behavior.

[yolo-sam]

[Haiku review] File extension comparison is case-sensitive

On case-insensitive filesystems (macOS APFS default), creating a file foo.HTM results in file.extension === "HTM". The isHtmlExtension type guard uses case-sensitive Array.includes(), so it will reject uppercase extensions.

Location: main.ts line 16-17 (isHtmlExtension definition), lines 184, 272, 368 (callers)

Impact:

• Users who create .HTM files with uppercase extensions won't be able to open them
• Same issue could affect .HTML (uppercase) files
• Tests only pass lowercase extensions, so this gap isn't caught

Fix: Normalize extensions to lowercase:

const isHtmlExtension = (ext: string): ext is HtmlExtension =>
  (HTML_EXTENSIONS as readonly string[]).includes(ext.toLowerCase());

[yolo-sam]

Pushing back on this one — the proposed fix doesn't address the actual gap, and the concern is pre-existing rather than introduced by this PR.

The fix is incomplete. Adding .toLowerCase() to isHtmlExtension only affects two call sites (canAcceptExtension at L184, resolveHtmlLink at L368). The actual routing of files to the view happens earlier, at Obsidian's registry layer:

this.registerExtensions([...HTML_EXTENSIONS], VIEW_TYPE_HTML);
embedRegistry.registerExtension(ext, ...);

These register the literal strings "html" and "htm" (lowercase) with Obsidian. When a file Foo.HTML exists, Obsidian's internal registry lookup for extension "HTML" won't match either entry — the file never reaches our canAcceptExtension, so the proposed guard fix is moot.

Pre-existing on main. The current code already had file.extension === "html" (L362) and extension === "html" (L180) — both case-sensitive. This PR didn't introduce the asymmetry; it just kept the existing behavior while adding .htm.

Actual fix would be broader. If we want case-insensitive support, we'd need to either register every case variant (["html", "HTML", "htm", "HTM"]) at the Obsidian API boundary, or confirm that Obsidian normalizes extensions internally before lookup (which would make the local guard redundant anyway). Either way, that's a separate scoped change, not part of "add .htm alias."

Out of scope here. If you want case-insensitive HTML routing, happy to open a separate issue. Deferring to @smcllns.

[yolo-sam]

[Haiku R3] Agree: Case-sensitivity concern is valid but fix is incomplete; pre-existing anyway.

Verified the pushback is technically sound:

1. Registry boundary gates file routing: Files are routed to the plugin via Obsidian's registerExtensions() and embedRegistry.registerExtension(), which register literal lowercase strings "html" and "htm". Files like Foo.HTML won't match at this layer and never reach the plugin's canAcceptExtension guard, so adding .toLowerCase() there doesn't help.

2. Pre-existing case-sensitivity: The original code had case-sensitive comparisons at line 180 (extension === "html") and line 362 (file.extension === "html"). This PR kept that behavior while adding .htm — didn't introduce the asymmetry.

3. Real fix is broader scope: Supporting case-insensitive extensions would require either registering all case variants at the Obsidian boundary or confirming Obsidian normalizes internally. That's out of scope for "add .htm alias."

The case-sensitivity concern is valid and could be addressed as a separate enhancement, but the proposed guard-only fix wouldn't solve it.