mirror of
https://github.com/heygen-com/hyperframes.git
synced 2026-11-04 21:17:30 +00:00
WaterrrForeverandClaude Opus 5
250c9bd509
readEngineVersion resolved ../../package.json relative to import.meta.url. That path is correct from packages/engine/src/utils/ in the repo and overshoots the package root from <pkg>/dist/ in the published CLI, which bundles the engine. The require threw MODULE_NOT_FOUND, a bare catch swallowed it, and every render stamped the 0.0.0-dev fallback. No single relative literal is correct in both layouts, so resolve by walking up to our own package root instead of by a fixed depth. The name check is the fix, not a refinement. A bare "first package.json found while walking up" resolves to whatever sits above in a hoisted install and returns a confident wrong version - the same class of defect as the sentinel, and harder to notice because the answer looks plausible. Only a package.json whose own name is hyperframes or @hyperframes/* may answer. A test pins this: removing the name check fails that case and only that case. Also replaces the sentinel. 0.0.0-dev parses as a version, compares against one, and sorts below every release, so a total resolution failure was indistinguishable from a dev build - which is why it shipped unnoticed. The fallback is now "unresolved", deliberately not semver-shaped, and every failure path warns with the reason. A failed lookup still never breaks a render. The old comment claimed the engine ships as raw TS and exports ./package.json. The published package has no exports field and bundles the engine, so that premise does not hold where the code runs; it is replaced with the two layouts and why they conflict. Refs #4365 Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>