无论是使用第三方库还是创建和分享自己的工具，npm都为我们提供了一个强大而便捷的平台，然而很多开发者在将自己的代码发布到npm上时往往面临各种困惑和挑战，本篇文章将从准备工作到发布上线，探讨如何让npm包更易发布及避免常见的坑，确保你开发流程更加顺畅

目录

npm发包准备

账号注册

镜像准备

npm发包操作

发布npm包

更新npm包

使用npm包

删除npm包

npm发包技巧

package配置

默认安装设置

npm发包准备

发布一个npm包看似简单实际上却需要做好充分的准备工作。包的结构、版本管理、依赖关系以及测试等都需要经过细致的规划和操作才能确保发布后的包稳定且易于维护，接下来将探讨在发布npm包之前开发者需要做哪些必要的准备工作，让包能够顺利发布并为其他开发者带来价值：

账号注册

在发布npm包之前我们要先确保直接已经注册过npm账号了，如果没有我们就需要先注册一个，因为npm的发包流程需要依赖这个账号，这里我们访问 官网 然后点击Sign Up 注册账号即可，如下图所示：

这里注意一下，注册npm的用户名一旦生效便不能再做更改，所以这里你要好好想一想：

注册成功之后，就会发一份邮件到你注册的邮箱账号上，注入验证码就可以登陆到我们npm的平台上了，如下所示：

镜像准备

要发布npm包的话对应的镜像一定是要切换到npm官方镜像，国内安装依赖一般都会切换其他镜像源，这里发包的话还是要切换到官方镜像，所以这里我们终端全局安装镜像源切换工具nrm，如下所示：

npm i -g nrm

nrm工具常用的镜像操作命令如下所示：

nrm -V // 查看当前nrm版本
nrm -h // 显示所有命令
nrm current // 显示当前镜像名称
nrm use <name> // 切换镜像
nrm add <name> <url> // 新增镜像
nrm del <name> // 删除镜像
nrm ls // 查看镜像列表
nrm test <name> // 测试镜像

通过如下指令我们就可以成功切换到npm官方镜像了：

npm发包操作

尽管npm提供了一个简单直观的发布方式，但要确保包的发布过程顺利进行并能为他人所用，还是需要掌握一些基本的发包技巧，当然博主也不能面面俱到讲解所有内容，具体命令参考：官网 这里不再过多赘述，如下所示：

接下来我们将一步步了解npm包发布的具体操作流程，从创建包到发布、更新版本、以及如何处理常见问题，让包在npm上顺利亮相，如下所示

发布npm包

项目初始化：接下来我们初始化一个项目并实现一段简单的代码来进行发包操作，首先终端执行如下命令初始化项目配置生成一个package.json文件，如下所示：

npm init

然后我们再新建一个入口文件index.js，实现两个简单的函数并暴露出去：

const addFn = (a, b) => a + b;
const subtractFn = (a, b) => a - b;export { addFn, subtractFn }

npm登录：接下来开始对我们的项目进行发包操作，首先我们先打开项目终端，执行如下发包流程进行发布操作，当我们终端现在执行npm login登录的时候，现在已经不需要在终端输入账户邮箱密码以及还有验证码内容了，我们登录npm官网的时候这里设置一个2FA双重验证操作，这里我们直接设置身份验证器选项的二次校验，如下所示：

当我们终端执行npm login登录的时候，直接回车就会弹出身份验证器界面，安装一个浏览器身份验证插件然后扫描QR码配置一下即可，后面直接输入验证码即可，无需输入账户密码等操作：

npm发包：发包前请确保package.json中name值没有和已有的包重复(npm官网查询)，如果包名重复，可以修改name或者使用npm作用域(Scoped Packages)，格式如：@yourusername/package-name，如果一切准备就绪，那么就开始执行如下命令发包：

npm publish

如下代码可以看到我们发包的一些相关信息，这里我们还需要进行身份验证(npm发包开始变得严格起来了)，回车然后还是输入浏览器生成的验证码即可：

如下提示我们发包失败了，主要原因还是因为我们定义的包名与npm平台已经存在的包及其相似，所以这里我们还是采用作用域命名的方式进行发包：

这里需要注意一下， 尝试发布一个带有作用域(比如@ztk63lrd/npm-test)的包，而这个包需要一个付费计划才能作为私有包发布，使用了带作用域的包名它默认会被当作私有包处理，除非你显式指定为公开包，通过如下指令将包设置为公开包就不需要付费计划：

npm publish --access public

如下我们可以看到我们的包发布完成，并且也显示了包的一些相关信息：

打开npm官网也可以看到我们的包已经成功被发布了：

更新npm包

更新npm包分为两步：第一步执行 npm version <版本号类型>，第二步执行npm publish，其更新包的常用命令如下所示：

// 第一步更新包：
npm version  major | minor | patch | premajor | preminor | prepatch | prerelease// 第二步发布包：
npm publish

npm的版本更新遵循语义化版本控制（Semantic Versioning，SemVer）即版本号由三部分组成：major.minor.patch，此外npm提供了更多的更新命令，如premajor、preminor等，下面简要说明这些更新命令的区别：

1）major：增加主版本号，表示不兼容的API更改，例如1.0.0升级到2.0.0通常意味着代码存在破坏性的变化，旧版本的代码可能无法正常工作。

2）minor：增加次版本号，表示向下兼容的功能新增，例如1.0.0升级到1.1.0通常表示添加了新特性或功能，但不会破坏现有功能的兼容性。

3）patch：增加修补版本号，表示向下兼容的问题修复，例如1.0.0升级到1.0.1通常是修复bug或改进性能，但不会影响功能或 API。

4）premajor：在major更新之前发布预发布版本，例如1.0.0升级到2.0.0-beta.0适用于发布破坏性改动的预览版本。

5）preminor：在minor更新之前发布预发布版本，例如1.0.0升级到1.1.0-beta.0适用于发布新功能的预览版本。

6）prepatch：在patch更新之前发布预发布版本，例如1.0.0升级到1.0.1-beta.0适用于发布修复的预览版本。

7）prerelease：发布预发布版本(通常是 alpha、beta 或 rc 版本)，这些版本通常包含未完全稳定的功能作为正式版本发布前的过渡，例如1.0.0升级到1.0.1-rc.0。

这些版本更新命令的区别主要体现在对版本号的影响和更新的稳定性上，开发者根据改动的性质选择合适的更新类型以确保对其他用户的影响最小，当然个人开发的话一般使用前三个命令即可：

接下来我们想生一次大版本，所以直接终端执行如下命令即可，这里我们不建议用户跳过命令直接修改package.json文件中的version字段，虽然也能修改版本但是避免用户可能会记错版本号从而导致版本错乱的情况：

改版之后直接点击发包，来到npm平台可以看到我们的包的版本也是重新被修改了：

使用npm包

这里我们直接终端安装我们发布的包即可，如下直接复制命令安装：

可以看到我们的包已经成功的被安装到node模块里面，并且也添加到了项目依赖上，版本号也是我们刚刚更新过的2版本：

接下来我们就需要直接在项目中使用包提供的方法即可，如下所示可以看到我们导入我们的包运行成功了，这里需要注意一下如果我们想设置ES的导入当时的话，需要在package包配置导入类型：

删除npm包

如果你发布了错误的包或者误发布的话，我们可以通过如下的命令来进行挽回操作，这里需要注意以下，如果报权限方面的错，加上--force即可。

1）删除某个版本：比如说我们发现我们发布版本的包有问题想删除并重新发布，这里我们可以执行如下命令操作即可：

npm unpublish 包名@版本号

删除完2版本之后，来到npm平台可以看到我们的包又回到了1版本：

这里需要注意一下，npm不允许使用已经被分配过的版本号(即使撤回或删除以前的版本号也被视作已分配)，如果要删除并且重新发布，需要重新发一个新版本，如删除2.0.0，发布2.0.1即可：

2）废弃某个版本： 通过如下命令可以在社区里不会撤销自己已有的包，但会在任何人尝试安装这个包的时候得到警告 例如：这个包已经不再维护：

npm deprecate 包名 '撤销警告'

如下我们通过对我们发布版本的包进行一个废弃操作：

在npm平台可以看到我们的包已经被成功废弃了，并且废弃的警告也是在平台显示了出来：

3）删除整个包：通过如下命令可以删除整个npm市场的包，不管该包有多少版本，直接一次性全部删除，这个命令需要慎用，当然可以在72小时内使用以下命令删除，但npm不允许删除已发布超过72小时的包，所以我们要慎重发布和删除，终端执行如下命令删除包：

npm unpublish 包名 --force

通过如下命令，我们就可以删除该包在npm市场上的所有版本：

来到npm平台，可以看到我们的包已经被成功删除了：

npm发包技巧

除了基本的包安装和管理，npm的更多高级功能往往被许多开发者忽视，了解并掌握这些进阶技巧能提升开发效率，接下来将深入探讨一些进阶的npm发包技巧，帮助在发布包时更加高效便捷并解决一些常见的发布问题，如下所示：

package配置

在前端项目中package.json文件是项目的配置文件，包含了项目的基本信息、依赖项、脚本命令等，为了方便后期的npm发包处理，了解package.json中的所有配置项非常重要，以下是各个配置项的详细说明：

1）基本信息：package.json中配置了以下基本信息字段，这也是发包常用的字段信息：

name: 项目的名称，npm包的唯一标识符。要求符合npm包命名规范（小写字母、破折号分隔，不能包含空格）。
version: 项目的版本号，遵循语义化版本控制，如 1.0.0。
description: 项目的简短描述，便于其他人了解该项目的功能。
main: 指定模块的入口文件，通常是 index.js，如果是库文件，npm安装时会默认加载此文件。
keywords: 一个字符串数组，用于描述包的关键词，便于搜索。
author: 项目的作者信息，可以是个人或组织的名称。
license: 项目的许可证类型，常见的如 MIT、ISC 等。

2）依赖配置：package.json中配置了以下依赖信息字段，里面分别是本地和生产的包信息：

// dependencies: 项目运行时所需要的依赖包。
// 这些依赖在生产环境中安装，例如：
"dependencies": {"react": "^17.0.0","axios": "^0.21.0"
}// devDependencies: 项目开发过程中所需的依赖包。
// 这些依赖仅在开发环境中安装，用于构建、测试等。例如：
"devDependencies": {"webpack": "^5.0.0","babel-loader": "^8.0.0"
}// peerDependencies: 该配置项声明当前包与其他包兼容的版本。
// 通常用于插件或库，确保与主应用兼容。例如：
"peerDependencies": {"react": "^16.8.0"
}// optionalDependencies: 可选的依赖包，安装时不会因为这些包安装失败而中断安装过程。适用于那些非关键依赖。

3）发布配置：publishConfig用于配置npm发布包时的行为，可以设置发布的tag、registry、access等：

"publishConfig": {"registry": "https://registry.npmjs.org/","access": "public"
}

4）其他配置：以下是完善发包的一些其他配置信息，可以根据自身需要进行设置：

// repository: 项目的代码仓库信息，通常用于 GitHub 或 GitLab。例如：
"repository": {"type": "git","url": "git+https://github.com/username/project.git"
}// bugs: 提交 bug 的网址，通常是一个指向 issues 页面的链接：
"bugs": {"url": "https://github.com/username/project/issues"
}// homepage: 项目的主页链接，通常指向项目的文档或网站。// engines: 定义项目支持的 Node.js 或 npm 的版本范围。例如：
"engines": {"node": ">=14.0.0","npm": "^6.0.0"
}// private: 如果设置为 true，表示该项目是私有的，发布到 npm 时会被拒绝。用于防止将不打算公开的包发布到 npm。
"private": true// config: 用于设置一些自定义的配置信息，供脚本中使用。例如：
"config": {"port": "8080"
}// directories: 用于配置一些特殊目录路径，如 lib、bin 等。例如：
"directories": {"lib": "src"
}// bin: 定义可执行文件的路径。例如：
"bin": {"my-cli": "./bin/cli.js"
}// files: 定义发布到 npm 时要包含的文件或目录。如果你不想将整个项目发布，可以通过 files 配置选择性地发布部分内容。
"files": ["dist","lib","README.md"
]

当然为了方便不用每次发包的时候都需要输入一遍命令，我们可以将命令设置在scripts中：

当我们执行了pub-beta命令，意味着我们要发布的是beta的包，发布成功之后就会给包打上一个beta的标记，意味着该包版本是预览版本，如下所示：

如果我们想安装预览版本的包的时候，需要在包名后添加一个@beta内容，如下所示：

npm i 包名@beta

默认安装设置

当我们发包之后，有多个版本的情况下，默认情况下用户安装的就是最新版本的包，如果想用户在不指定包版本的情况下载，默认安装我们设置好的版本包(不一定是最新版本的)，可以通过如下命令进行设置，这样做就是为了方便预览版本进行时间验证：

npm dist-tag add 指定包<版本> latest

如下可以看到我们可以给0.1.1版本打上latest标签：

后面用户如果没有安装过该包的话，不指定版本直接安装就会安装0.1.1版本的包，如果已经安装了该包的其他版本，可以先删除该包然后再安装依赖即可，ok，目前基础的讲解就暂时这些吧，后面博主将继续深入讲解一下关于npm发包的一些实用技巧！