Start
Foundations
Design Systemv1.3.0Search documentation
Search for a command to run or a page to navigate to.
Design Systemv1.3.0Search for a command to run or a page to navigate to.
Every authenticated path — the package, styles-only, the code-quality presets, and the codemod — needs the same .npmrc setup. It has two parts:
A committed project .npmrc that points the @strongtie scope at the Simpson
feed. Holds no secret.
Locally, in your user ~/.npmrc; in CI, written from a secret at build time.
Never committed.
.npmrcCreate a .npmrc in your project root with a single line, and commit it:
@strongtie:registry=https://pkgs.dev.azure.com/StrongTie/_packaging/Simpson/npm/registry/Scope the key to @strongtie: — not a global registry=. A bare registry=
pointed at the feed routes every install through it and makes public
packages like sonner fail with E401.
Don't add always-auth. npm has ignored it since 7.10.0 — it always sends
credentials to a registry once they're configured — and current npm warns that
it's an unknown config key.
The project .npmrc above only routes the scope — it carries no credentials. How you supply them depends on where npm runs.
Credentials go in your user-level ~/.npmrc (~ is your home directory), never in the project file.
ado-npm-authMicrosoft's cross-platform ado-npm-auth helper signs you in with your Simpson Microsoft account and writes the auth block into ~/.npmrc for you — macOS, Linux, and Windows alike (it's the cross-platform successor to the Windows-only vsts-npm-auth). It uses short-lived Entra (Azure AD) tokens instead of a long-lived PAT, so there's nothing to rotate.
# run from your project root, where the scoped .npmrc lives
npm exec ado-npm-authThe first run opens a browser to sign you in. It downloads the azureauth CLI from the public registry, so if your shell defaults npm elsewhere, point it back for that one command:
npm_config_registry=https://registry.npmjs.org npm exec ado-npm-authado-npm-auth is pre-1.0 and needs an interactive Microsoft sign-in. If
npm install still returns E401 afterward, use the PAT block below.
If you can't sign in interactively (or prefer a token), create an Azure DevOps Personal Access Token scoped to Packaging → Read, then add it to ~/.npmrc. The quickest source is Azure DevOps itself — Artifacts → Simpson → Connect to feed → npm → Other shows a ready-made block with the token already base64-encoded. To build it by hand, encode the PAT with echo -n 'YOUR_PAT' | base64 and paste the result as _password in both blocks:
; begin auth token
//pkgs.dev.azure.com/StrongTie/_packaging/Simpson/npm/registry/:username=StrongTie
//pkgs.dev.azure.com/StrongTie/_packaging/Simpson/npm/registry/:_password=BASE64_ENCODED_PAT
//pkgs.dev.azure.com/StrongTie/_packaging/Simpson/npm/registry/:email=npm requires email to be set but doesn't use the value
//pkgs.dev.azure.com/StrongTie/_packaging/Simpson/npm/:username=StrongTie
//pkgs.dev.azure.com/StrongTie/_packaging/Simpson/npm/:_password=BASE64_ENCODED_PAT
//pkgs.dev.azure.com/StrongTie/_packaging/Simpson/npm/:email=npm requires email to be set but doesn't use the value
; end auth tokenWhy two nearly identical blocks? npm binds credentials to an exact
registry path. The feed is addressed both as …/npm/registry/ (installs) and
…/npm/ (some publish and whoami calls), so each needs its own entry
carrying the same encoded token.
npm view @strongtie/design-system versionThis should print a version number. An E401 or ENEEDAUTH means your credentials are missing or wrong; a "not found" means your scope routing is off. See Troubleshooting.