fix(cli): read actual data-width/data-height in info command

[miguel-heygen]

PR Stack

#	PR	Status
1	#122 — fix: info width/height swap	← base
2	#123 — fix: include all 9 templates in build
3	#124 — fix: suppress ANSI in non-TTY
4	#125 — fix: lint --json error paths
5	#126 — fix: separate info/warning counts
6	#127 — fix: lint severity display
7	#128 — fix: render output path error
8	#129 — fix: zero-duration error message	← top

---

Summary

• The info command was hardcoding dimensions based on portrait/landscape detection, which always defaulted to "portrait" because parseHtml() doesn't read data-width/data-height from composition root elements
• Now reads the actual attribute values directly from the HTML

Reproducer

npx hyperframes init test --template blank --non-interactive
cd test && npx hyperframes info
# Shows "1080x1920" (portrait) but index.html has data-width="1920" data-height="1080"
npx hyperframes info --json | jq '{width, height}'
# Was: {"width": 1080, "height": 1920}
# Now: {"width": 1920, "height": 1080}

Stack

1/8 — This is part of a stack of bug fixes found during automated new-user testing.

🤖 Generated with Claude Code

[miguel-heygen]

• fix(engine,cli): download headless-shell instead of using system Chrome for local renders #131
• fix(cli): improve error message for zero-duration composition renders #129
• fix(cli): catch output directory creation errors in render #130
• fix(cli): distinguish info vs warning severity in lint output #127
• fix(core): separate info count from warning count in linter results #126
• fix(cli): respect --json flag on lint error paths #125
• fix(cli): suppress ANSI escape codes in non-TTY progress output #124
• fix(cli): include all 9 templates in build output #123
• fix(cli): read actual data-width/data-height in info command #122 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[miguel-heygen]

Two issues:

1. Regex matches the wrong element

The regex /data-width\s*=\s*["'](\d+)["']/ matches the first occurrence of data-width anywhere in the raw HTML. In HyperFrames, data-width/data-height appear on every composition element, not just the root. For example, play-mode/index.html has data-width on the root at line 95 but also on child compositions at lines 104, 138, 198, 208, 218. If source order ever changes, or a script/style block contains the string, this returns wrong dimensions.

compositions.ts already solves this correctly with DOM queries:

const width = parseInt(div.getAttribute("data-width") ?? "1920", 10);
const height = parseInt(div.getAttribute("data-height") ?? "1080", 10);

2. Dimension parsing belongs in parseHtml / ParsedHtml

The info command already calls parseHtml(html) which creates a full DOM document internally. Rather than duplicating dimension extraction via regex in the CLI, extend ParsedHtml in @hyperframes/core with width and height fields, populated by DOM-based attribute reads from the root composition element. This makes the core parser the single source of truth.

Also: the JSON output schema changed — resolution went from a "landscape"/"portrait" enum to a "1920x1080" string. This is a breaking change for consumers of hyperframes info --json.

[miguel-heygen]

Addressed: replaced regex with DOM query via doc.querySelector("[data-composition-id]") (same approach as compositions.ts). Preserved resolution as landscape/portrait enum in JSON for backward compat.

[miguel-heygen]

Consolidated into fix/cli-polish.