nodejs/node · error · Error

${providerEntity} must be specified with ${entityKey} option

Error message

${providerEntity} must be specified with ${entityKey} option or inferred from the package.json repository field

What it means

Thrown by TrustCommand.flagsToOptions when no entity was resolved (no flag and no usable package.json repository) AND the positional matches the package.json name (or was omitted), i.e. matchPkg is true. The message tells the user the entity must come from the entityKey flag (e.g. --project) or be inferred from the package.json repository field. This is the 'package.json is the source of truth but has no repository info' branch.

Source

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

    }

    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)

    return {
      values: {
        package: pkgName,
        file: flags.file,
        [entityKey]: entity,
        ...(flags.environment && { environment: flags.environment }),
      },
      fromPackageJson: {
        [entityKey]: usedRepositoryInPkgJson,
        package: usedPkgNameFromPkgJson,
      },

View on GitHub (pinned to 1b2de5e052)

Solutions

  1. Pass the entity flag for the provider: `--project group/proj` (gitlab) or `--repo owner/repo` (github).
  2. Add a parseable `repository` field to package.json (URL or `gitlab:group/proj` shorthand) so it can be inferred.
  3. Verify hosted-git-info can parse your repository string; prefer a full HTTPS URL.

Example fix

// before
// package.json: { "name": "pkg" }  (no repository)
npm trust gitlab --file .gitlab-ci.yml --allow-publish
// after
npm trust gitlab --file .gitlab-ci.yml --project group/proj --allow-publish
Defensive patterns

Strategy: validation

Validate before calling

const git = gitinfo.fromUrl(pkg.repository?.url || pkg.repository)
if (!entity && matchPkg) {
  throw new Error(`No ${providerEntity} resolvable; pass --${entityKey} or set package.json#repository`)
}

Type guard

const hasResolvableEntity = (entity, flags, entityKey) =>
  Boolean(entity) || Boolean(flags && flags[entityKey])

Try / catch

try {
  await createConfigCommand(...)
} catch (err) {
  if (/inferred from the package.json repository field/i.test(err.message)) {
    // set package.json#repository to a parseable URL or pass --project, then retry
  } else { throw err }
}

Prevention

When it happens

Trigger: Running `npm trust gitlab --file .gitlab-ci.yml --allow-publish` with a package.json that has a name but no `repository` field (or one hosted-git-info cannot parse), and no `--project`. matchPkg true means this branch fires; if a positional that doesn't match were given, error 77 would fire instead.

Common situations: Fresh package without repository metadata; repository field is a bare string that hosted-git-info doesn't recognize; you meant to pass --project but forgot.

Related errors


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