要与一组有限的用户或团队共享你的代码,你可以将私有用户范围或组织范围的包发布到 npm 注册表。
🌐 To share your code with a limited set of users or teams, you can publish private user-scoped or organization-scoped packages to the npm registry.
有关作用域和私有包的更多信息,请参见 "关于范围" 和 "关于私有包"。
🌐 For more information on scopes and private packages, see "About scopes" and "About private packages".
注意: 在你发布私有用户作用域的 npm 包之前,你必须注册一个付费的 npm 用户账户。
此外,要发布面向私有组织的包,你必须先创建一个 npm 用户账户,然后创建一个付费的 npm 组织。
🌐 Additionally, to publish private organization-scoped packages, you must create an npm user account, then create a paid npm organization.
🌐 Creating a private package
如果你正在使用 npmrc 来 在多个注册表上管理账户,在命令行中,切换到相应的配置文件:
npmrc <profile-name>
在命令行上,为你的包创建一个目录:
mkdir my-test-package
导航到包的根目录:
cd my-test-package
如果你使用 git 来管理你的包代码,在包的根目录下运行以下命令,并将 git-remote-url 替换为你的包的 git 远程 URL:
git initgit remote add origin git://git-remote-url
在包的根目录中,运行 npm init 命令,并将作用域传递给 scope 标志:
对于面向组织的包,将 my-org 替换为你的组织名称:
npm init --scope=@my-org
对于用户范围的包,将 my-username 替换为你的用户名:
npm init --scope=@my-username
根据提示生成package.json文件。有关包命名的帮助,请参见"包名指南"。
创建一个 自述文件 来解释你的软件包代码是什么以及如何使用它。
在你首选的文本编辑器中,为你的包编写代码。
🌐 Reviewing package contents for sensitive or unnecessary information
将敏感信息发布到注册表可能会对你的用户造成伤害,危及你的开发基础设施,修复成本高昂,并使你面临法律风险。我们强烈建议在将软件包发布到注册表之前删除敏感信息,例如私钥、密码、个人可识别信息(个人身份信息)和信用卡数据。 即使你的软件包是私有的,如果软件包被公开或下载到可能被更多用户访问的计算机上,敏感信息仍可能被泄露。
🌐 Publishing sensitive information to the registry can harm your users, compromise your development infrastructure, be expensive to fix, and put you at risk of legal action. We strongly recommend removing sensitive information, such as private keys, passwords, personally identifiable information (PII), and credit card data before publishing your package to the registry. Even if your package is private, sensitive information can be exposed if the package is made public or downloaded to a computer that can be accessed by more users than intended.
对于不太敏感的信息,例如测试数据,请使用 .npmignore 或 .gitignore 文件以防止发布到注册表。更多信息,请参见 这篇文章。
🌐 For less sensitive information, such as testing data, use a .npmignore or .gitignore file to prevent publishing to the registry. For more information, see this article.
🌐 Testing your package
为了减少发布错误的可能性,我们建议在将包发布到 npm 注册表之前先测试你的包。要测试你的包,请使用包含包目录完整路径的命令 npm install:
🌐 To reduce the chances of publishing bugs, we recommend testing your package before publishing it to the npm registry. To test your package, run npm install with the full path to your package directory:
npm install my-package
🌐 Publishing private packages
默认情况下,范围包以私有可见性发布。
🌐 By default, scoped packages are published with private visibility.
有两种方法可以将你的包发布到 npm 注册表:
🌐 There are two ways to publish your package to the npm registry:
🌐 Direct publishing
要直接与 npm publish 发布,你需要以下任一条件:
🌐 To publish directly with npm publish, you need either:
欲了解更多信息,请参阅 npm 关于发布包时要求两步验证的文档。
🌐 For more information, see the npm documentation on requiring 2FA for package publishing.
在命令行上,导航到包的根目录。
cd /path/to/package
要将你的私有包发布到 npm 注册表,请运行:
npm publish
要查看你的私有包页面,请访问 https://npmjs.com/package/*package-name*,将 package-name 替换为你的包名称。私有包在 npm 网站上的包名称下方会显示 private。
有关 publish 命令的更多信息,请参阅 命令行接口文档。
🌐 For more information on the publish command, see the CLI documentation.
🌐 Staged publishing
你可以先将你的包发布到暂存区,然后再批准它,而不是直接发布。将包发布到暂存区不需要双因素认证,这允许 CI 工作流将包提交到暂存区域。在包发布到注册表之前,维护者必须使用双因素认证进行审核和批准。
🌐 Instead of publishing directly, you can stage your package and approve it later. Staging the package does not require 2FA, which allows CI workflows to submit a package to the staging area. Before the package is published to the registry, a maintainer must review and approve it with 2FA.
绕过 2FA 的 GAT 在分阶段包批准过程中不会绕过 2FA 检查。
🌐 A GAT with bypass 2FA does not bypass the 2FA check during staged package approval.
在命令行上,导航到包的根目录。
cd /path/to/package
要暂存你的软件包,请运行:
npm stage publish
这会将你的包提交到暂存区。
要检查你的封装是否已被分拣,可使用以下任一方法:
npm stage list <package-name> 来查找已暂存的软件包及其暂存 ID。要批准并发布分阶段包,请使用以下方法之一:
npm stage approve <stage-id> 命令。注意: 无论你是在 CLI 中还是在 npmjs.com 上批准该软件包,都将提示进行双因素认证(2FA)验证。一旦批准,该软件包将发布到实时注册表中。
有关完整的分阶段发布工作流程,包括审核、检查和拒绝分阶段的软件包,请参见 分阶段发布。
🌐 For the full staged publishing workflow, including reviewing, inspecting, and rejecting staged packages, see Staged publishing.