packall

Errors are named after what went wrong and carry the detail with them. This page covers the ones that need more than the message.

Cannot reach registry

Registry unreachable: Cannot reach registry https://registry.npmjs.org/: no response within 10000ms.
  Check your network connection, VPN, and the proxy settings in your .npmrc.

The run checks the registry before doing anything, so this appears in the first seconds rather than after a long silence. Nothing waits longer than --timeout.

The detail after the colon is the failure as the socket reported it — ENOTFOUND is DNS, ECONNREFUSED is a host that answered and said no, a timeout is silence. Treat it as the thing to search for.

If the registry is genuinely slow rather than unreachable, raise the ceiling:

packall --file package.json --timeout 30000

…because the certificate was not trusted

Registry unreachable: Cannot reach registry https://artifactory.corp/api/npm/npm/: UNABLE_TO_GET_ISSUER_CERT_LOCALLY: unable to get local issuer certificate.
  The registry's certificate was not trusted by this machine's store — which is
  usual for an internal CA. Point cafile in your .npmrc at your CA bundle, or set
  NODE_EXTRA_CA_CERTS. strict-ssl=false turns verification off entirely.

Nothing is wrong with your network here, and checking the VPN will not show otherwise. Any code naming a certificate — UNABLE_TO_GET_ISSUER_CERT_LOCALLY, SELF_SIGNED_CERT_IN_CHAIN, DEPTH_ZERO_SELF_SIGNED_CERT — means the chain the registry presented does not lead back to a CA this machine trusts. See Private registries.

…and the host named is not the one you configured

Registry unreachable: Cannot reach registry https://registry.npmjs.org/: …

If the URL in the message is not the one in your .npmrc, something outranked the file. Almost always that is npm_config_registry, which npm run and pnpm run export into every script they start — so packall called from a package.json script uses your package manager's registry, even with --npmrc pointing somewhere else. The same cause produces Package "x" was not found on https://registry.npmjs.org/ when the network can reach npm.

--registry outranks everything, including the environment. The full order is in Private registries.

…because a proxy stands in the way

Proxy configuration is the one part of .npmrc that is not read: proxy and https-proxy are ignored, and so are HTTP_PROXY and HTTPS_PROXY in the environment. If reaching your registry requires a proxy, npm install will succeed where this fails.

Registry rejected the request

Authentication: Registry https://artifactory.corp/api/npm/ rejected the request with HTTP 401.
  Add credentials to your .npmrc, e.g.
    //artifactory.corp/api/npm/:_authToken=${NPM_TOKEN}

The suggested line is the one to add. Two things catch people out:

${NPM_TOKEN} expands from your environment. If the variable is not set, it expands to an empty string and you get a 401 explaining none of that.
The key is scoped to a host and path. A token registered against //artifactory.corp/:_authToken does not apply to //artifactory.corp/api/npm/.

No published version satisfies…

No matching versions: No published version of react satisfies "^19.9".
  Most recent published versions: 19.2.6, 19.2.7, 19.2.8

The range matched nothing. If you expected a prerelease to match, they are excluded unless you ask:

packall react@^19 --include-prerelease

Integrity check failed

Integrity: Integrity check failed for lodash@4.17.21.
  expected: sha512-…
  actual:   sha512-…
  The download was discarded. This is either corruption in transit or a tampered artifact.

The run stops. This is the check working — do not reach for --no-verify to get past it. A proxy that rewrites or re-compresses tarballs is the usual innocent explanation; the other one is the reason integrity checking exists.

The lockfile does not cover this

Lockfile incomplete: ./pnpm-lock.yaml is incomplete — these dependencies are not pinned:
    tslib
    @types/node
  Run pnpm install to refresh it.
  Or pass --lockfile off to resolve version ranges fresh instead.

A pinned run is pinned all the way down, so a gap is a failure rather than a silent fallback to range resolution — that mismatch is exactly what the lockfile was there to prevent. Either refresh the lockfile, or resolve fresh:

packall --file package.json --lockfile off

Output file already exists

Output error at ./bundles/react@19.2.8.tgz: file exists

Without --force, an existing file is a question rather than an overwrite. In CI, decide up front:

packall --file package.json --force --yes --out ./bundles

Two packages want the same archive name

Output: Output error at ./bundles: two packages want the same archive name —
@a/b-c@1.0.0 and @a-b/c@1.0.0 would both be @a-b-c@1.0.0.tgz. The `/` in a scope
becomes a `-` to make a file name, so `@a/b-c` and `@a-b/c` meet. Use --layout
single, or bundle them into separate --out directories.

The run refuses before downloading and names both specs rather than letting one land on the other. --layout single writes one archive and has no per-spec names to collide.

It runs out of memory in the browser

ENOSPC: in-memory filesystem byte limit exceeded

The browser runner holds everything in the tab. --layout single packs each package once instead of once per spec, which is usually enough:

packall --file package.json --layout single

For a manifest large enough that no layout makes it fit, run the command on your own machine. There is no such ceiling there.

A package is missing from the bundle

Check bundle-manifest.json — reasons says which edge pulled each package in, and a package that is not listed was never resolved. The usual causes:

--no-optional or --platform narrowed the native binaries.
--no-peer dropped a peer dependency npm would auto-install.
The dependency is a workspace:, file: or git entry, which cannot come from a registry. Those are reported as warnings and skipped.

Troubleshooting