要在用户或组织命名空间中公开共享你的代码,你可以将公共用户范围或组织范围的包发布到 npm 注册表。
🌐 To share your code publicly in a user or organization namespace, you can publish public user-scoped or organization-scoped packages to the npm registry.
有关作用域的更多信息,请参见“关于范围”。
🌐 For more information on scopes, see "About scopes".
注意: 在你可以发布用户级别的 npm 包之前,你必须注册 一个 npm 用户账户。
此外,要发布组织范围的包,你必须先创建一个 npm 用户账户,然后创建一个 npm 组织。
🌐 Additionally, to publish organization-scoped packages, you must create an npm user account, then create an npm organization.
🌐 Creating a scoped public 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.
对于不太敏感的信息,例如测试数据,请使用 .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 /path/to/my-test-package
🌐 Publishing scoped public packages
默认情况下,带作用域的包是以私有可见性发布的。要以公共可见性发布带作用域的包,请使用 npm publish --access public。
🌐 By default, scoped packages are published with private visibility. To publish a scoped package with public visibility, use npm publish --access public.
有两种方法可以将你的包发布到 npm 注册表:
🌐 There are two ways to publish your package to the npm registry:
🌐 Direct publishing
要直接在 npm publish --access public 上发布,你需要以下任一条件:
🌐 To publish directly with npm publish --access public, you need either:
欲了解更多信息,请参阅 npm 关于发布包时要求两步验证的文档。
🌐 For more information, see the npm documentation on requiring 2FA for package publishing.
在命令行上,导航到包的根目录。
cd /path/to/my-test-package
要将范围公共包发布到 npm 注册表,请运行:
npm publish --access public
注意: 如果你使用 GitHub Actions 发布你的软件包,你可以为你发布的每个软件包生成来源信息。更多信息,请参见 "生成出处声明"。
要查看你的公共包页面,请访问 https://npmjs.com/package/*package-name*,将 package-name 替换为你的包名称。在 npm 网站上,公共包的包名下会显示 public。
有关 publish 命令的更多信息,请参阅 命令行接口文档。
🌐 For more information on the publish command, see the CLI documentation.
🌐 Staged publishing
你可以选择暂存你的软件包,然后稍后再批准它,而不是直接发布。暂存软件包不需要双重认证(2FA),这允许持续集成(CI)工作流将软件包提交到暂存区。在软件包公开可用之前,维护者必须使用双重认证(2FA)进行审核和批准。
🌐 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 becomes publicly available, 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/my-test-package
要发布你的 scoped 公共包,请运行:
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.