pnpm/pnpm · error · PnpmError

NOT_SUPPORTED_ARCHIVE

NOT_SUPPORTED_ARCHIVE

Error message

The binary fetcher doesn't support archive type ${resolution.archive}

What it means

The binary fetcher switches on resolution.archive and only handles the archive kinds it implements (tarball, zip, and a directory form); the resolution carried any other value, hitting the default case. This means the lockfile or a resolver produced an archive type this fetcher version cannot handle — usually a hand-edited lockfile or a resolver/fetcher version mismatch.

Source

Thrown at pnpm11/fetching/binary-fetcher/src/index.ts:92

        await downloadAndUnpackZip(ctx.fetch, {
          url: resolution.url,
          integrity: resolution.integrity,
          basename: resolution.prefix ?? '',
          ignoreEntry: archiveFilter?.regex,
        }, tempLocation)
        fetchResult = await addFilesFromDir({
          storeDir: cafs.storeDir,
          storeIndex: ctx.storeIndex,
          dir: tempLocation,
          filesIndexFile: opts.filesIndexFile,
          readManifest: false,
          appendManifest: manifest,
          includeNodeModules: true,
        })
        break
      }
      default: {
        throw new PnpmError('NOT_SUPPORTED_ARCHIVE', `The binary fetcher doesn't support archive type ${resolution.archive as string}`)
      }
    }
    return {
      ...fetchResult,
      manifest,
    }
  }
  return {
    binary: fetchBinary,
  }
}

export interface AssetInfo {
  url: string
  integrity: string
  basename: string
  /**
   * Regex matched against each zip entry's path relative to the archive's top-level basename.

View on GitHub (pinned to 5b11d3a15b)

Solutions

Regenerate resolutions: delete pnpm-lock.yaml (or revert the edit) and run pnpm install
Use one consistent pnpm version across the team and CI
Never hand-edit resolution fields; express intent in package.json or overrides and let pnpm re-resolve

Example fix

# before - hand-edited lockfile
tarball:
  resolution:
    archive: targz     # unsupported value

# after - regenerate
rm pnpm-lock.yaml && pnpm install

Defensive patterns

Strategy: validation

Validate before calling

const SUPPORTED_ARCHIVE_TYPES = new Set(['tarball', 'zip', 'dir'])
function hasSupportedArchiveType (resolution: { archive?: string }): boolean {
  return resolution.archive == null || SUPPORTED_ARCHIVE_TYPES.has(resolution.archive)
}
// validate lockfile resolutions before install; regenerate if any fail

Try / catch

catch code === 'NOT_SUPPORTED_ARCHIVE'; regenerate the lockfile (rm pnpm-lock.yaml && pnpm install) or re-run with the pnpm version that produced it

Prevention

Never hand-edit resolution objects in pnpm-lock.yaml
Keep one pnpm version across the team and CI so lockfile vocabulary stays consistent
Validate lockfiles in CI after any programmatic rewriting

When it happens

Trigger: resolution.archive set to an unknown string: manual pnpm-lock.yaml edits, a lockfile written by a different pnpm version with a different archive vocabulary, or corrupted resolution objects.

Common situations: Editing lockfiles to 'fix' resolutions; switching between incompatible pnpm versions; third-party tools rewriting lockfiles incorrectly.

Related errors

AI-assisted analysis of pnpm/pnpm@5b11d3a15b (2026-08-16). Data as JSON: /api/errors/40bea69baaf65680. Report an issue: GitHub.