feat(registry): add hex registry support for elixir, phoenix, and phoenix_live_view

[wbisschoff13]

Adds Hex.pm ecosystem support to the registry with three packages and a version fetcher.

Changes:

• packages/registry/src/version-check.ts — adds fetchHexVersions() that queries https://hex.pm/api/packages/{name} for automated version discovery, matching the existing npm/pip/maven fetchers

• registry/hex/elixir.yaml — unversioned (git source from elixir-lang/elixir, lib/ docs path). Elixir is not a Hex package (language runtime), so it builds from HEAD as latest. Covers gradual set-theoretic types docs

• registry/hex/phoenix.yaml — versioned via Hex API, covers v1.5.0+, docs from guides/ directory

• registry/hex/phoenix_live_view.yaml — versioned via Hex API, covers v0.17.0+, docs from guides/ directory

Why this matters:

The registry currently has 100+ packages across npm, pip, and maven but zero Hex/Elixir packages. These three cover the core Elixir web ecosystem. The hex fetcher makes adding more packages trivial.

Verification:

• All 199 existing tests pass
• Lint clean across both packages
• Packages built and tested locally (see screenshots in README)
• guides/ directory verified at HTTP 200 across all tagged versions back to the min_version ranges

[changeset-bot]

⚠️ No Changeset found

Latest commit: 115a552

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[moshest]

Nice addition — the hex fetcher matches the npm/pip/maven ones cleanly and the wiring looks right.

A few things before merge (details inline):

• The phoenix and phoenix_live_view files each have two identical version entries. I checked the tags and they build the same way, so let's collapse each to one.
• elixir.yaml points docs_path at lib, which is source code. Worth checking the built output — the guides live under lib/elixir/pages.

Couple of small ones too:

• A test for fetchHexVersions would be good — there's already one for maven in version-check.test.ts to copy.
• The module comment at the top of version-check.ts still says "(npm, pip, maven)" — add hex.

Thanks!

---

Generated by Claude Code

[moshest]

These two entries are identical apart from the range. I checked guides/ at both v1.5.0 and v1.7.0 — same path, same v{version} tag scheme on both sides. So the split doesn't actually change anything at build time.

Can we collapse it to one?

versions:
  - min_version: "1.5.0"
    source:
      type: git
      url: https://github.com/phoenixframework/phoenix
      docs_path: guides
    tag_pattern: "v{version}"

---

Generated by Claude Code

[moshest]

Same thing here. guides/ is there at both v0.17.0 and v0.20.0 with the same path and tag scheme, so the two entries are doing the same job. Let's fold them into one:

versions:
  - min_version: "0.17.0"
    source:
      type: git
      url: https://github.com/phoenixframework/phoenix_live_view
      docs_path: guides
    tag_pattern: "v{version}"

---

Generated by Claude Code

[moshest]

lib/ is mostly Elixir source, not docs. The build filters to .md/.mdx/etc, so this'll scrape stray markdown rather than the real guides, which live in lib/elixir/pages/. Can you double-check what ends up in the built package? docs_path: lib/elixir/pages is probably what you want.

---

Generated by Claude Code

[moshest]

Looks good — all three points from the earlier review are addressed:

• phoenix.yaml / phoenix_live_view.yaml — collapsed to a single version entry each
• elixir.yaml — docs_path now points at lib/elixir/pages

The fetchHexVersions() fetcher cleanly mirrors the npm/pip/maven pattern (retry, encodeURIComponent, defensive defaults), and the YAML entries follow existing registry conventions. Ordering/dedup/prerelease filtering are handled downstream in discoverVersions, consistent with the other fetchers.

No changeset is required: the only modified package is @neuledge/registry (private: true, never npm-published), @neuledge/context is untouched, and the hex docs ship via the data-driven registry-update workflow regardless. Nothing in CI gates on it.

Approving. 🚀

---

Generated by Claude Code