npm 进阶命令知多少(一)

前言

作为前端模块化扎展现形式的npm包，已经在前端开发中不可或缺，熟练掌握npm相关内容，也是前端开发者的一门必修课，那么除了npm publish这类常见内容之外，还有哪些内容需要我们关注呢，下面就一起深入看看。

npm publish 发布npm包

该命令简单粗暴，执行之后，就会将相关文件上传到远端，并为对应包新增一个对应版本号。那么这里的相关文件和对应版本具体是哪些呢，不知道大家有没有关注过。

发布哪些文件

一个指令爽的飞起，包发布完成了，问题是发了什么上去呢，万一有些不能对外暴露的文件被download下去，问题可能就大了。因此npm允许开发者通过配置来指定待发布内容。
可以分为以下几种情况来指定:

1. 当前包目录下，只要.npmignore存在，那么以.npmignore为准，没有被.npmignore忽略的内容都会被上传，即使.gitignore已经忽略该文件。毕竟是专用配置文件，优先级最高。
2. 不存在.npmignore，但有.gitignore，会以.gitignore为准。这里也说得过去，一般无需通过git进行管理的文件，一般是无关内容，例如.vscode等环境配置相关。
   例如，vue就只有 .gitignoe 大家可以看下安装的包里面存不存在相关文件。
3. 没有.gitignore 或者 .npmignore，上所有文件都会上传。
4. 有一种情况例外，package.json中存在files字段，可以理解为files为白名单，ignore文件为黑名单。

   files:["src","types"]
   

这里有个问题：当.npmignore和files内容冲突时，那个优先级高呢。答案是以files为准,
可以通过npm pack 命令进行本地测试：

// .npmignore
.DS_Store
node_modules
.gobble*
dist
src
// package.json
"files": [
    "src",
    "dist",
    "README.md"
  ]
// 打包测试
npm pack  

项目根目录下会生成一个压缩包这就是将要上传的文件内容，打开后可以发现，src文件夹是存在的。

举个栗子
再举个比较明显的例子，vue@2.6.12 其配置如下：

//files
"files": [
   "src",
   "dist/*.js",
   "types/*.d.ts"
 ]
 // .gitignore
 .DS_Store
node_modules
*.log
explorations
TODOs.md
dist/*.gz
dist/*.map
dist/vue.common.min.js
test/e2e/reports
test/e2e/screenshots
coverage
RELEASE_NOTE*.md
dist/*.js
packages/vue-server-renderer/basic.js
packages/vue-server-renderer/build.js
packages/vue-server-renderer/server-plugin.js
packages/vue-server-renderer/client-plugin.js
packages/vue-template-compiler/build.js
.vscode

这样的话，vue对外开放的npm包中，只包含有files定义的文件和package.json、README.md这些文档类文件。

为什么有额外这些文档类呢，原因在于这些信息传递的文件，npm是规定不允许忽略的，只有存在就会上传：

• package.json
• README (and its variants)
• CHANGELOG (and its variants)
• LICENSE / LICENCE

ignore语法格式
.npmignore语法跟.gitignore相同，上面的例子也体现出了相关语法，这里就不粘贴了。

至于什么样的文件夹可以被认定为包目录：
这里的定义比较复杂

常见的就是包含有package.json的文件夹，我们记住这个就行了。

具体到实际开发中，monorepo那种单仓库多包的形式，每个子包显然也是一个包目录，可以进行独立的npm包管理行为。

举个例子：

• vue下的packages的vue-template-compiler ，就是单独发布为一个vue-template-compiler包的。
• 根目录发布为vue包，忽略掉了packages下的一些内容

总结

这一小段的核心就是，指定需要上传的文件时有两种方式：

1. 白名单形式： files字段，优先级最高，该字段以外的文件，除了信息类，其他的都忽略。
   适用于，文件夹多，需要上传的文件夹少的情况，例如vue这种。
2. 黑名单形式: .npmignore 或.gitignore， npmignore优先级较高。
3. 都不指定，包目录下所有内容都上传。

发布什么版本

明确了发布的内容之后，发布的版本也是有要求的。通用的就是遵循语义化版本规范，部分内容摘抄如下：

版本格式：主版本号.次版本号.修订号，

版本号递增规则如下：

主版本号：当你做了不兼容的 API 修改，

次版本号：当你做了向下兼容的功能性新增，

修订号：当你做了向下兼容的问题修正。

先行版本号及版本编译元数据可以加到“主版本号.次版本号.修订号”的后面，作为延伸。

先行版本：

alpha: 内部版本

beta: 公测版本

rc: 即Release candiate，正式版本的候选版本

作为业界公认的规范，只有大家都遵循之后，才能形成整个生态的统一和谐，否则一方升级版本之后，使用者都不敢跟进，那么就不要谈以后的发展了。

版本哪里来
版本通过package.json里面的version字段来确定：

 "version": "1.0.0",

每一版本号是唯一的，假如发布了1.0.0,下次更新必须要进行更新，否则会提醒。

npm ERR! [forbidden]cannot modify pre-existing version: 1.0.1

自动更新
有人说，每次都要手动更新版本太麻烦，或者万一改错了就不好了。 是否有命令行可以替我自动执行这些操作。

这里要说一下，因为版本的确定还是一个依赖于内容决定的主观性动作，所以不可能全自动的通过工具实现，谁知道你改的内容是否向下兼容，这里作为开发者要有自己的判断。

因此只能实现个半自动操作:

npm version  opt
// 这里opt 的取值如下，跟语义化版本是对应的。
patch, minor, major, prepatch, preminor, premajor, prerelease

官方解释：
Run this in a package directory to bump the version and write the new data back to package.json, package-lock.json, and, if present, npm-shrinkwrap.json.

不仅会根据指令自动升级版本，升级幅度为1。而且会回写到下面文件中package.json, package-lock.json, and, if present, npm-shrinkwrap.json。
这里有个点需要注意，如果是在git仓库下，还会自动创建一个版本commit和tag，可以通过下面的指令避免：

npm --no-git-tag-version version

举个例子：

// 当前版本 1.0.0
 "version": "1.0.0",
// 升级大版本好
npm version major
// 执行后当前结果
 "version": "2.0.0",

总结

这一节的重点就在于介绍了升级版本的半自动操作，虽然本地开发时看起来半自动提升不明显。
但是在ci/cd中，就可以结合git，实现升版本，push代码的联合操作。
避免忘记修改版本重新发布的情况。

谁来发布

前面讲到了发布npm的直接一步，但这之前还需要个前置步骤。那就是登录了，否则作为一个成熟的系统，游客随便就进行修改操作了，那也太可怕了。

常规操作：

npm login
-> npm login
Username: 
Password:
Email: (this IS public)

依次执行就可以了，假如不确定是否登录，可以通过查看命令来看：

npm whoami

登录完成之后，不一定可以发布指定包，需要具备权限（这也是要我们登录的原因，鉴权嘛），假如没有，可以让有权限的同学通过下面命令添加：

// 给zhangshan增加pkg1 包的发布权限
npm owner add zhangshan pkg1

假如某一天登录态过期了，那么我们又要重新执行这些操作了。那么是否可以有方式配置自己的登录态呢，这就要依赖.npmrc这个文件了。

npmrc

npm的配置文件，相关配置项可以参考：https://www.npmjs.cn/misc/config/
例如我们常见的修改为淘宝源，除了通过如下命令行的形式外：

npm config set registry https://registry.npm.taobao.org

还可以通过.npmrc来配置

.npmrc的位置

作为基本的配置项，npm的设置还是非常灵活的，允许用户自定义来满足定制化需求，但是用户一般只会修改几项，所以一般我们会遇到四个是.npmrc的文件：

• 每个项目的配置文件，位置是： (/path/to/my/project/.npmrc)
• 每个用户的配置文件，位置是：(~/.npmrc)
  因为每个计算机可以有多个用户。
• 全局配置文件，位置是 ($PREFIX/etc/npmrc)
• npm 内置配置文件，位置是 (/path/to/npm/npmrc)
  全局都有了，为啥还有个内置呢，避免不完全修改，做个备份。

这四个文件的优先级是自上而下组件减小的
这样也可以理解，用户的修改项目本地文件是最低成本且不会造成其他影响的，所以优先级最高，npm内置的优先级最低。

其内容都是key-value的形式。
举个例子：

// 随手从网上找了个：
prefix=D:Program Files
odejs
ode_global
cache=D:Program Files
odejs
ode_cache
registry=https://registry.npm.taobao.org

假如要修改用户名，在其中进行修改即可。

结束语

本来想一篇就把npm的相关内容介绍完毕，没想到随便展开一下就很多了，本文就到这里吧，其他的后面再行更新。本文是一篇学习笔记，部分内容没有展开讲，有兴趣的同学可以直接官网深究。
因为精力和能力有限，如果有疏漏，忘不吝指正。
更多博客请转