> For the complete documentation index, see [llms.txt](https://docs.flxbl.io/flxbl/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flxbl.io/flxbl/codev/integrations/package-registries/npm.md).

# 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](/flxbl/codev/integrations/source-control/github.md) integration; the others (npm, JFrog, GitLab) are configured as their own integrations.

{% content-ref url="/pages/C2gHJRUnEQc5yR3yqRJ1" %}
[JFrog Artifactory](/flxbl/codev/integrations/package-registries/jfrog.md)
{% endcontent-ref %}

## Variables vs. this integration

Storing an `NPM_TOKEN` as a [variable or secret](/flxbl/codev/ci-cd/variables.md) 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](https://docs.flxbl.io/sfp-server) documentation.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.flxbl.io/flxbl/codev/integrations/package-registries/npm.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.