docs(registry): explain installer metadata - #3658
Conversation
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Automations to automatically generate PRs for you. |
miguel-heygen
left a comment
There was a problem hiding this comment.
Reviewed 81c133ca2a5680c2421b15ea95fee3536ccfc854; no actionable findings.
docs/contributing/catalog.mdx:94 correctly limits the compatibility guarantee to item files: runAdd can write the project config first, then gates every resolved dependency before installation. The dependency ordering, missing/cyclic dependency rejection, and non-blocking deprecation wording match the current resolver and compatibility implementation.
Checked both complete diffs and the underlying add/resolver/compatibility paths. JSON examples parse, Markdown fences balance, and GitHub docs validation, formatting, CodeQL, and Mintlify deployment passed; runtime jobs were skipped for this docs-only change. No prior substantive reviews to duplicate. No dependencies installed or local runtime tests run.
Verdict: APPROVE
Reasoning: The documentation accurately describes the current installer and keeps the change limited to the missing guidance.
— Magi
The catalog lists installer metadata fields but does not explain their behavior. Document transitive dependencies, minimum CLI versions, and deprecation warnings in the current catalog and CLI guides.
Refreshes #1410 by @kiyeonjeon21, preserving the original author. The current installer gates all resolved items before writing item files; it may create hyperframes.json earlier, so the wording makes that distinction.
Validation: traced current add/resolver/compatibility code; 25 existing registry tests pass; catalog JSON examples, Markdown fences, and git diff checks pass. The repository formatter does not support MDX. No runtime changes.