Uh oh!
There was an error while loading. Please reload this page.
Browser coverage for the polyglot fan-out in the registry UI - #5
Merged
Conversation
The zed-cli polyglot workflow proves the artifacts are well-formed -- isolated, test-free, natively publishable -- but never puts them in a registry a human navigates. Nothing covered the other half: that one publish of a multi-language repo leaves the registry in a state where a consumer of any single language can find and install exactly their package. Adds publishPolyglotFixture()/ensurePolyglotSeeded() and a four-language seed whose slices each carry their ecosystem's own native manifest, then asserts through a real browser that each language is a separate page with its own install snippet, that the whole-repository target coexists with the slices, that the polyglot source name is deliberately NOT a package, that every slice shares one version and provenance tag, and that the slices are distinct artifacts rather than aliases of one fat tarball. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Uh oh!
There was an error while loading. Please reload this page.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
zed-clipolyglot workflow proves the artifacts are well-formed — isolated, test-free, natively publishable. It never puts them in a registry a human navigates. This covers the other half.What it asserts
One
zed publishof a four-language repository, then through a real browser:[targets.repository] dir = \".\", the goal-2 surface)acme-clients404s whileacme-clients-<target>resolve. Without this, consumers could depend on a name whose contents are undefined.sha256, because identical digests would mean the registry is serving one fat tarball under several names, which is exactly the design doc 17 rejectedCovered on Playwright and mirrored on Puppeteer, matching this repo's multi-engine convention for the MASH/HTMX UI.
Verification
npm run typecheckpasses. Docker was unavailable in the authoring environment, so the live stack was not exercised locally; the fixture manifest and the exact package set every assertion depends on were verified against a realzed publishinto afile://registry:acme-clientsitself is absent, confirming the 404 assertion. CI runs the suites against the live stack.Gap this coverage surfaces
There is nothing in the UI to assert about a package's language.
package.language/package.ecosystemare declared in the manifest and enforced by the install guard, but they never reach the registry API DTOs (PackageMetadata,PackageSummary) or the web UI. Browsing the registry,acme-clients-javais indistinguishable from any unrelated package, and the language guard can only act after download rather than being advertised up front. Worth a follow-up.🤖 Generated with Claude Code