chore: upgrade hosted-git-info to v10

[josemarluedke]

Follow-up to #213, which deliberately left hosted-git-info at v3 because v4+ removed browsetemplate in favour of .edit()/.browse() — an unrelated refactor of repo-info.ts.

Why v9 and not v10

Engines by major:

major	engines
v8	^18.17.0 || >=20.5.0
v9	^20.17.0 || >=22.9.0
v10	^22.22.2 || ^24.15.0 || >=26.0.0

Docfy declares ^20.19.0 || >=22.12.0, which is a strict subset of v9's range. v10's range is narrower than docfy's, so adopting it would force an engines bump on every consumer — out of scope here.

Why the URL is assembled by hand

Neither .edit() nor .browse() can produce what Docfy needs. In v9 every *template is a function, and both helpers percent-encode the path, which mangles the literal {filepath} placeholder Docfy substitutes later. On top of that, GitLab's .edit() emits -/edit rather than the legacy /edit, and Bitbucket's edittemplate emits only ?mode=edit without Docfy's &spa=0&at=…&fileviewer=… tail.

So the URL is now built from the parsed host metadata (repo.domain / repo.user / repo.project), which are still first-class properties on GitHost. getTreePath is untouched.

Supported hosts are now an explicit whitelist

The first cut of this change imposed one URL shape on every host hosted-git-info can parse, which meant sourcehut got a plausible-looking but wrong edit URL where it previously got none. getTreePath only knows two shapes — Bitbucket's, and the /edit/ form GitHub and GitLab accept — so the three real ones are now listed explicitly and everything else returns null. No edit link beats a broken one, and this also means a future hosted-git-info release that learns a new host can't silently produce garbage.

Behaviour: verified, not asserted

Both implementations were compiled and run against an identical root argument (so git-root differences don't skew the comparison) over 10 input URLs × {default, custom branch}:

• All 14 GitHub/GitLab/Bitbucket lines byte-identical, including the GitLab subgroup case (user comes back as "group/sub"), SSH git@host: forms, and .git suffixes. The literal un-encoded {filepath} is preserved throughout.
• sourcehut: null before, null after (the intermediate regression above was demonstrated and then closed).
• not-a-repo-url: null before and after.

One intentional change:

input	before	after
https://gist.github.com/…	https://gist.github.com/…{/committish}	null

The old value was an artifact of naive string substitution — gist's browsetemplate has no {/tree/committish} token, so nothing was replaced, leaving a literal {/committish} and no {filepath} at all. It was never a usable edit URL and no test covers it.

Known follow-up

@types/hosted-git-info stays at ^3.0.5 — DefinitelyTyped never published typings for v4+ and v9 ships none. The stale package still describes the five members actually used (fromUrl, type, domain, user, project) correctly, but is wrong about *template being a string and its Hosts union doesn't know sourcehut exists. There's a comment at the import saying so. The clean fix is dropping the @types dependency for a small hand-written ambient declaration; left out as scope creep.

Also worth knowing: GitLab keeps the legacy /edit/ path rather than /-/edit/, per the no-URL-change constraint. Worth revisiting if GitLab ever drops the redirect.

Verification

pnpm -r run compile clean; @docfy/ember-vite 60/60; @docfy/plugin-with-prose 2/2; eslint clean. @docfy/core shows 6 failures which are the known worktree-only ones (git-repo-info reports a root containing the worktree path) — every failure differs from expected by nothing but that path prefix, and #213's CI run confirms they pass on a normal checkout.

🤖 Generated with Claude Code

[josemarluedke]

Updated to v10 per maintainer decision, as an additional commit rather than a force-push so the v9 step stays reviewable.

• hosted-git-info → ^10.1.1
• engines.node → ^22.22.2 || ^24.15.0 || >=26.0.0 in all four published packages, kept in sync so a consumer installing @docfy/ember-cli on Node 20 gets a warning from every package rather than just core
• docs updated: the old text justified the floor as "the Node versions that support require() of ES modules", which no longer explains the number (that landed in 20.19/22.12). getting-started and the upgrade guide now separate the two constraints, and the upgrade guide states plainly that this drops Node 20 entirely and 22.12 → 22.22.

Behaviour re-verified against the original v3 baseline rather than against v9, since v10 could have changed host parsing — it didn't. All 16 GitHub/GitLab/Bitbucket URLs byte-identical; gist and sourcehut null. The whitelist needed no changes.

CI's node-version: 24.x already satisfies the range (currently resolves to 24.19.0), so that file is untouched — #214 also touches it. Worth noting the floating pin satisfies ^24.15.0 only because 24.19 happens to be past 24.15; pinning 24.15.x or later would make the intent explicit.

⚠️ One consequence worth a decision before merge. The range excludes Node 23 and all of Node 25, because it mirrors hosted-git-info's LTS-shaped range. Anyone developing on a current odd-numbered Node — including this repo on Node 25.5.0 — now gets an Unsupported engine warning from all four packages on every pnpm install. Warnings only; everything installs, compiles and tests fine. If that's unwanted noise, >=22.22.2 would keep the same practical floor while admitting odd releases.

[josemarluedke]

Engines widened to >=22.22.2 per maintainer decision, resolving the warning I flagged above.

Mirroring hosted-git-info's own ^22.22.2 || ^24.15.0 || >=26.0.0 meant declaring support for LTS lines only, which excluded Node 23 and all of Node 25 — so every install in this repo (Node 25) warned from all four packages. A plain >= keeps the same practical floor.

Two things checked rather than assumed:

• Zero engine warnings on install now, and hosted-git-info does not start warning in their place. pnpm only reports engine mismatches for workspace projects, not for third-party dependencies, so declaring a wider range than a dependency doesn't shift the warning onto it.
• The docs rationale was rewritten, not renumbered. The previous text said Docfy "matches hosted-git-info's range rather than depending on a package it does not support" — that's no longer what we do, so leaving it would have been a stale justification attached to a new number for the second time in this PR. getting-started now notes the dependency expresses its range as a list of LTS lines and that Docfy deliberately uses >= instead.

Also in this PR since the last update: @types/hosted-git-info is gone, replaced by a local declaration of the five members repo-info.ts actually uses. v10.1.1 ships no types (no types field, no .d.ts in the tarball) and DefinitelyTyped never went past 3.0.5, so the alternative was type-checking against a four-major-old contract that is wrong about *template being strings and doesn't know sourcehut exists. Nothing leaks into the public API — the emitted repo-info.d.ts never mentions GitHost.

Templates regenerated for the changed prose; the diff contains no editUrl changes.