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
- Pass the entity flag for the provider: `--project group/proj` (gitlab) or `--repo owner/repo` (github).
- Add a parseable `repository` field to package.json (URL or `gitlab:group/proj` shorthand) so it can be inferred.
- 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
- Set a parseable `repository` field in package.json for inference.
- Provide the explicit entity flag to avoid relying on inference.
- Use HTTPS repository URLs; avoid bare strings hosted-git-info cannot classify.
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
- Package name must be specified either as an argument or in t
- Package name must be specified either as an argument or in t
- Package name must be specified either as an argument or in p
- Repository in package.json is not a ${providerEntity}
- ${providerEntity} must be specified with ${entityKey} option
AI-assisted analysis of nodejs/node@1b2de5e052 (2026-08-13).
Data as JSON: /api/errors/50bf739e237b8a61.
Report an issue: GitHub.