nodejs/node · error · Error

Repository in package.json is not a ${providerEntity}

Error message

Repository in package.json is not a ${providerEntity}

What it means

Thrown by TrustCommand.flagsToOptions when the package.json repository resolves (via hosted-git-info) to a DIFFERENT provider type than the command (e.g. a GitHub URL while running `npm trust gitlab`) AND no explicit `--project`/`--repo` flag was given. With a mismatched type the inferred entity is unreliable, so the command refuses to silently use it; providing the flag demotes the same condition to a warning instead of an error.

Source

Thrown at deps/npm/lib/trust-cmd.js:288

    const warnings = []
    if (!pkgName) {
      throw new Error('Package name must be specified either as an argument or in package.json file')
    }

    if (!flags.file) {
      throw new Error(`${providerFile} must be specified with the file option`)
    }
    if (!flags.file.endsWith('.yml') && !flags.file.endsWith('.yaml')) {
      throw new Error(`${providerFile} must end in .yml or .yaml`)
    }

    this.validateFile?.(flags.file)

    if (invalidPkgJsonProviderType) {
      const message = this.warnString`Repository in package.json is not a ${providerEntity}`
      if (!flags[entityKey]) {
        throw new Error(message)
      } else {
        warnings.push(message)
      }
    } else {
      if (mismatchPkgJsonRepository) {
        warnings.push(this.warnString`Repository in package.json (${git.repository}) differs from provided ${providerEntity} (${entity})`)
      }
    }

    if (!entity && matchPkg) {
      throw new Error(`${providerEntity} must be specified with ${entityKey} option or inferred from the package.json repository field`)
    }
    if (!entity) {
      throw new Error(`${providerEntity} must be specified with ${entityKey} option`)
    }

    this.validateEntity(entity)

View on GitHub (pinned to 1b2de5e052)

Solutions

  1. Pass the explicit entity flag for the provider you are configuring: `--project group/proj` for gitlab, `--repo owner/repo` for github.
  2. Update the package.json `repository` field to match the provider you intend to trust.
  3. Switch to the correct provider subcommand that matches your repository (`npm trust github` vs `npm trust gitlab`).

Example fix

// before
// package.json: "repository": "github:owner/repo"
npm trust gitlab --file .gitlab-ci.yml --allow-publish
// after
// keep package.json as-is, supply the project explicitly
npm trust gitlab --file .gitlab-ci.yml --project gl-group/gl-proj --allow-publish
Defensive patterns

Strategy: validation

Validate before calling

const git = gitinfo.fromUrl(pkg.repository?.url || pkg.repository)
if (git && git.type !== providerName && !flags[entityKey]) {
  throw new Error(`package.json repository is a ${git.type} URL but you are configuring ${providerName}; pass --${entityKey} explicitly`)
}

Type guard

const repoTypeMatchesProvider = (pkg, providerName) => {
  const info = gitinfo.fromUrl(pkg.repository?.url || pkg.repository)
  return !info || info.type === providerName
}

Try / catch

try {
  await createConfigCommand(...)
} catch (err) {
  if (/Repository in package.json is not a/i.test(err.message)) {
    // pass the explicit entity flag (e.g. --project group/proj) and retry
  } else { throw err }
}

Prevention

When it happens

Trigger: package.json `repository` points to github.com but you run `npm trust gitlab` without `--project`; or repository is a gitlab URL but you run `npm trust github`. invalidPkgJsonProviderType = matchPkg && git && git.type !== name; the throw fires inside that branch when flags[entityKey] is absent.

Common situations: Mirrored repos (canonical on GitHub, mirror on GitLab) where repository still points to the original; renaming a repo and leaving stale metadata; running the wrong provider subcommand.

Related errors


AI-assisted analysis of nodejs/node@1b2de5e052 (2026-08-13). Data as JSON: /api/errors/ded8e1e47a113309. Report an issue: GitHub.