You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am in corporate environment where public npm registry is blocked.
even If I set NPM_CONFIG_REGISTRY , vp install still failing as it is not using the apikey
here is what Claude say:
Root cause found. Your package.json pins "packageManager": "pnpm@11.24.0" (package.json:52). Like Corepack, vp downloads that exact pnpm binary into its own managed store (~/.vite-plus/package_manager/pnpm, currently empty on your machine) rather than using whatever pnpm is on PATH. That download is done by vp's own Rust binary hitting the npm-style tarball URL directly — it's a separate code path from the pnpm/npm CLI that reads ~/.npmrc.
Verified this in two parts:
Registry choice: vp only honors the NPM_CONFIG_REGISTRY env var for this download (documented default https://registry.npmjs.org). Since that env var isn't exported in your shell (only present in ~/.npmrc), vp falls back to public npm.
Auth: even after exporting NPM_CONFIG_REGISTRY to your Artifactory URL, the download 401s — vp's downloader doesn't send the Bearer token from your .npmrc's _authToken. I confirmed with curl that the same URL only succeeds with an Authorization: Bearer header; Basic auth (token-as-username) fails too, so there's no URL-embedded-credential workaround.
So this is a real gap: for a pinned packageManager version, vp can't authenticate to a token-only private registry when fetching the manager itself.
Practical options:
Ask your Artifactory admin if the mirror also accepts Basic auth with your AD username + an API key/identity token (common JFrog setup) — if so, NPM_CONFIG_REGISTRY=https://<user>:<apikey>@xyz.jfrog.io/... would let vp's downloader authenticate via URL-embedded Basic auth.
Pre-seed the cache once from a machine/network that can reach the registry with proper auth (e.g. have plain pnpm dlx pnpm@11.24.0 --version or similar populate ~/.vite-plus/package_manager/pnpm manually), then subsequent vp install runs won't need to re-download it.
Report this to vite-plus (viteplus.dev) as a gap — package-manager bootstrap doesn't support authenticated private registries beyond NPM_CONFIG_REGISTRY.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
I am in corporate environment where public npm registry is blocked.
even If I set
NPM_CONFIG_REGISTRY,vp installstill failing as it is not using theapikeyhere is what Claude say:
Root cause found. Your package.json pins "packageManager": "pnpm@11.24.0" (package.json:52). Like Corepack, vp downloads that exact pnpm binary into its own managed store (~/.vite-plus/package_manager/pnpm, currently empty on your machine) rather than using whatever pnpm is on PATH. That download is done by vp's own Rust binary hitting the npm-style tarball URL directly — it's a separate code path from the pnpm/npm CLI that reads ~/.npmrc.
Verified this in two parts:
So this is a real gap: for a pinned packageManager version, vp can't authenticate to a token-only private registry when fetching the manager itself.
Practical options:
NPM_CONFIG_REGISTRY=https://<user>:<apikey>@xyz.jfrog.io/...would let vp's downloader authenticate via URL-embedded Basic auth.All reactions