fix(create): read org manifest from the tarball when the registry strips createConfig#2063
Open
hiro-daikin wants to merge 6 commits into
Open
Conversation
✅ Deploy Preview for viteplus-preview canceled.
|
…ips createConfig Some registries — GitHub Packages among them — store only the package.json fields the npm CLI requires, so custom fields like createConfig are absent from packument version metadata even though the published tarball preserves the full package.json. readOrgManifest only consulted the packument, so vp create @org:name failed with 'No createConfig.templates manifest' for any org package hosted on such a registry. When the resolved version metadata lacks createConfig entirely (as opposed to present-but-empty) and advertises dist.tarball, download the tarball and read createConfig from its package.json, reusing the existing download, integrity-check, and tar-parsing machinery. Behavior is unchanged for compliant registries (no extra request), 404s, empty template arrays, and malformed manifests (still OrgManifestSchemaError). Fixes voidzero-dev#2062
63545c4 to
4517135
Compare
Member
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4517135f13
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
A probe failure (download, size cap, integrity, parse) on a normal @scope/create package without a manifest must not block the passthrough path that previously handled it — degrade to 'no manifest' instead. Schema errors stay loud: validateManifest runs outside the try, so a manifest that is present but malformed still throws.
fengmk2
approved these changes
Jul 6, 2026
fengmk2
left a comment
Member
There was a problem hiding this comment.
@hiro-daikin Thanks! I will run a round simplify before I merge.
- collapse the best-effort probe try/catch to `.catch(() => null)` and drop the redundant initializer and duplicated rationale comment - share a `requestUrl` fetch-input helper across the test mocks instead of copy-pasting the URL-extraction dance - hoist the tarball URL into a single `TARBALL_URL` constant reused by the `packument` default, and pass the `Uint8Array` body straight to `Response`
new Response(Uint8Array) is valid at runtime but not assignable to BodyInit under the CI TypeScript lib; pass the ArrayBuffer via .slice().buffer.
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 free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Fixes #2062 (thanks @fengmk2 for the invitation to contribute the fix).
Problem
vp create @org:nameresolves the org template catalog by fetching the registry packument and readingversions[x].createConfig. Some registries — GitHub Packages among them — store only the package.json fields the npm CLI requires, so custom fields likecreateConfigare absent from packument version metadata even though the published tarball preserves the full package.json byte-for-byte. (Per the npm registry spec, full version objects should carry all publisher fields — npmjs.org does — but alternative registries demonstrably don't; the same behavior was hit by Renovate's npm-hosted presets in renovate#8266, where GitHub Support confirmed "only the fields required by the NPM CLI are stored".)Result:
No \createConfig.templates` manifest in @org/create — `@org:name` requires one.` for any org package hosted on such a registry, no matter how it was published.Fix
When the resolved packument version metadata lacks
createConfigentirely (as opposed to present-but-empty) and advertisesdist.tarball, download the tarball and readcreateConfigfrom itspackage.json— the one artifact every registry preserves verbatim. NewreadPackageJsonFromTarballhelper inorg-tarball.tsreuses the existingdownloadTarball(streaming + 50 MB cap + auth viafetchNpmResource),verifyIntegrity,parseTarGzip, andnormalizeEntryName(so only the rootpackage/package.jsonmatches).Behavior is unchanged everywhere else:
requestedVersionresolution → unchangedcreateConfigpresent buttemplates: []→ still "no manifest", no fallback fetchOrgManifestSchemaErrorKnown trade-off: in the fallback path the tarball can be downloaded twice (once for the manifest read, once later by
ensureOrgPackageExtractedfor bundled entries — which has its own on-disk cache). Kept the diff minimal; happy to thread the bytes into the extraction cache in this PR or a follow-up if you prefer.Validation
org-manifest.spec.ts(fallback success with a real in-testnanotar.createTarGzipfixture and matching sha512 integrity; both-sources-missing → null; fast-path fetch-count assertion); full spec 39/39, package unit suite green,tsgoclean,vp fmt --checkclean.sha512integrity verified.create-generator-monorepotimed out in my local environment — its path doesn't involve the org-manifest code; expecting CI to confirm).Two adjacent issues from #2062 are intentionally not addressed here to keep the diff focused: the unauthenticated-first fetch not retrying on 404 (some registries 404 unauthenticated metadata), and the error message conflating not-found / auth-gated / field-stripped. Happy to follow up on either.