vp create @org:name fails on GitHub Packages — createConfig is read from the packument, which GHP strips custom fields from

[hiro-daikin]

Summary

vp create @org:name fails with No `createConfig.templates` manifest in @org/create — `@org:name` requires one. for org packages published to GitHub Packages (npm.pkg.github.com), even though the published tarball's package.json contains a valid createConfig.templates.

Root cause: vp create reads createConfig only from the registry packument (readOrgManifest → fetchPackument → packument.versions[resolved].createConfig in dist/create/bin.js), and GitHub Packages strips custom fields from packument version metadata — the field survives in the tarball but is absent from the metadata document. Public npmjs.org preserves custom fields, which is why this only bites alternative registries.

Environment

• vite-plus 0.1.24, Node 24.x, macOS + Linux (reproduced on both)
• Org package @daikin-dsv/create published to GitHub Packages with @daikin-dsv:registry=https://npm.pkg.github.com in .npmrc

Evidence

Version metadata returned by GitHub Packages for the published version (authenticated GET https://npm.pkg.github.com/@daikin-dsv/create):

fields present: _hasShrinkwrap, _id, _nodeVersion, _npmUser, _npmVersion, author, bugs,
description, directories, dist, files, gitHead, homepage, license, name, readme,
repository, version
createConfig present: false        <-- stripped by the registry

The same version's tarball package.json (via npm pack @daikin-dsv/create):

createConfig present: true -> templates: ["template", "template-examples"]

So any org package on GitHub Packages will always fail the validateManifest check (raw.createConfig is undefined → null → the error above), regardless of what was published. Registries aren't required to preserve arbitrary custom fields in packument version documents, so relying on them there is fragile by design (same field-trimming happens with e.g. pacote.manifest() without fullMetadata).

Two adjacent issues found while tracing this

1. Auth retry gate misses GitHub Packages 404s. fetchNpmResource sends the first request unauthenticated and only retries with the .npmrc token on 401/403. GitHub Packages frequently answers unauthenticated metadata reads with 404, which fetchPackument maps to null — producing the same "no manifest" error without the token ever being sent. Consider sending credentials proactively when the scope's registry has a matching //host/:_authToken, or retrying on 404 for scope-mapped registries.
2. The error message conflates three failure modes: package genuinely absent (404), auth-gated 404, and "package found but createConfig missing from the packument". Printing the resolved registry URL and distinguishing "not found" from "found but no manifest field" would have made this diagnosable in seconds.

Suggested fix

When the resolved packument version lacks createConfig, fall back to downloading meta.dist.tarball (already fetched later for bundled ./ templates anyway) and reading createConfig from the tarball's package.json. That makes org templates registry-agnostic — the tarball is the one artifact every registry preserves byte-exact.

Repro

1. Publish a minimal @yourscope/create with createConfig.templates: [{name, description, template: "./templates/x"}] and a bundled templates/x/ to GitHub Packages.
2. @yourscope:registry=https://npm.pkg.github.com (+ authToken) in .npmrc.
3. vp create @yourscope:x my-app → No `createConfig.templates` manifest in @yourscope/create.
4. curl -H "Authorization: Bearer <PAT>" https://npm.pkg.github.com/@yourscope/create | jq '.versions[."dist-tags".latest? // "<version>"].createConfig' → null, while the tarball contains the field.

Happy to provide more detail — we've worked around it for now by adding a bin to our @org/create (the tarball-based npm create @org convention is unaffected), but we'd love vp create @org:name to work on GitHub Packages.

[fengmk2]

@hiro-daikin Thank you for such detailed feedback. This is indeed an issue that we hadn't considered. Would you be willing to fix it?

[hiro-daikin]

Gladly — PR up: #2063. It adds a tarball fallback in readOrgManifest: when the resolved packument version lacks createConfig entirely but advertises dist.tarball, the manifest is read from the tarball's package.json (reusing the existing download/integrity/tar machinery). Validated with unit tests plus an end-to-end replay of a real GitHub Packages packument+tarball pair — the release CLI reproduces the failure, the patched CLI scaffolds. The auth-on-404 and error-message points from this issue are left for a follow-up to keep the diff focused.