npm Registry

The npm Registry integration gives codev's workflows authenticated access to a private npm registry, so your builds and pipelines can install (and publish) private npm packages without you committing tokens to your repository.

You configure it under Settings > Organization > Integrations > npm Registry. Only organization owners can manage it.

What the npm integration does

codev stores your registry URL and access token, and uses them to generate an authenticated .npmrc on demand when a workflow needs it — for example, when a build or validation step installs private dependencies. The token is never written into your repository; codev produces the .npmrc at run time and the workflow consumes it.

This integration is for registry access (installing and publishing packages). It is not where you publish your Salesforce artifacts — that is part of the build and release pipeline.

Configuration

Field	What you provide
Registry URL	The registry to authenticate against. Defaults to https://registry.npmjs.org. For a private registry, enter its full URL.
Access Token	A registry access token (npm_… for npmjs.com).
Scope (optional)	An npm scope without the leading @ (e.g. my-org). Defaults to the repository owner if left blank.

Creating an access token

1. On npmjs.com, go to Account Settings > Access Tokens (or the equivalent on your private registry).
2. Click Generate New Token.
3. Choose an Automation token for CI/CD use.
4. For a private registry, also enter that registry's full URL in the Registry URL field.

How scope is resolved

When codev builds the .npmrc, the scope is chosen in this order:

1. A scope explicitly requested by the workflow
2. The Scope set on the integration
3. The repository owner (the first segment of owner/repo), lower-cased

Which registry codev uses

The npm Registry integration is one of several artifact registry integrations codev can authenticate to. When more than one is configured, codev chooses one in this order:

1. Whichever artifact-registry integration is marked default, then
2. By type, in the order: GitHub Packages → JFrog → npm → GitLab Package Registry

So if you configure more than one registry, mark the one your workflows should use as the default for the artifact-registry category. To switch the active registry later, mark a different integration as the default — codev clears the previous one automatically, and the next .npmrc it generates points at the new registry. GitHub Packages authentication is drawn from your GitHub integration; the others (npm, JFrog, GitLab) are configured as their own integrations.

JFrog Artifactory

Variables vs. this integration

Storing an NPM_TOKEN as a variable or secret is a separate, manual mechanism — useful when your own workflow scripts read SFP_SECRET_NPM_TOKEN directly. The npm Registry integration is the managed alternative: codev resolves the credential and generates the .npmrc for you. Use one or the other depending on how your workflow consumes the registry.

Scoping and precedence

Each integration is either Global (all projects) or scoped to a specific project, and a global integration can be marked the default. When codev needs a registry credential for a project, it picks the most specific match:

1. An integration scoped to that project
2. The integration marked default for the artifact-registry category
3. A global integration

Self-hosting

The npm Registry integration works the same on a self-hosted instance. Server-level configuration is covered in the sfp server documentation.