The EPRIVATE error occurs when you attempt to publish a package that has "private": true in its package.json. This field is a safeguard that prevents npm from publishing the package at all, regardless of destination registry.
Fixes npm ERR! code EPRIVATE npm ERR! This package has been marked as private
{
"name": "my-package",
"version": "1.0.0",
"private": true
}{"name": "my-package","version": "1.0.0","private": true}npm ERR! code EPRIVATEnpm ERR! This package has been marked as private
The "npm ERR! code EPRIVATE" error occurs when you attempt to publish a package to the npm registry, but the package.json file contains "private": true. This field is a safeguard that prevents npm from publishing the package at all, regardless of destination registry. The "private" field is specifically designed to block publication entirely—it's not a mechanism for creating "private packages" in the sense of restricted access. If you want to publish packages with restricted access, you must remove this field and instead use npm's paid private package features or a private registry. This is npm working as designed, protecting you from accidentally publishing internal code.
Edit your package.json and delete the line containing "private": true:
Before:
{
"name": "my-package",
"version": "1.0.0",
"private": true
}After:
{
"name": "my-package",
"version": "1.0.0"
}Then run: npm publish
If publishing an organization-scoped package (@myorg/package-name):
1. Remove "private": true from package.json
2. Ensure your package.json name uses the scope:
{ "name": "@myorg/my-package" }3. Publish with appropriate access level:
- For private (requires paid account): npm publish
- For public: npm publish --access public
If you want to publish to a private registry (GitHub Packages, Verdaccio, Artifactory):
1. Remove "private": true from package.json
2. Create or edit .npmrc with the appropriate registry:
Example for GitHub Packages:
//npm.pkg.github.com/:_authToken=YOUR_GITHUB_TOKEN
@yourorg:registry=https://npm.pkg.github.com/3. Publish: npm publish
In a monorepo with workspaces:
1. Keep "private": true in the root package.json (prevents accidental root publication)
2. Remove "private": true from workspace packages that should be published
// Root package.json (keep private)
{ "private": true, "workspaces": ["packages/*"] }
// packages/my-lib/package.json (remove private)
{ "name": "@myorg/my-lib", "version": "1.0.0" }Publish individual workspaces:
npm publish --workspace=packages/my-libIf you want restricted access (not blocking publication):
npm Private Packages (paid):
- Requires paid npm account
- Only scoped packages can be private
- Publish with: npm publish
GitHub Packages (free):
- Free, no paid npm account required
- Configure .npmrc with GitHub token
- Collaborators need GitHub access to install
Remove "private": true and use registry access controls instead.
Understanding the distinction:
The npm ecosystem uses "private" in two different ways:
1. package.json "private" field = "Do not publish this package anywhere" (a safeguard)
2. "Private packages" on npmjs.com = "Published packages with restricted access" (requires paid account)
These are fundamentally different concepts.
Why this safeguard exists: The "private" field was added to prevent accidents. Developers often clone repositories or run npm commands in the wrong terminal. Without this safeguard, internal code could be accidentally published to the public registry.
Common monorepo patterns: It's standard to mark the root package.json as private while individual workspace packages are publishable.
Scoped package naming: When publishing privately, always use scoped names (@myorg/internal-package). Scoped packages default to private when published with a paid account.