npm publish package 测试流程
原创
上一篇 npm publish package 发布流程 中说了开发的过程，但是对于测试和调试部分并没有过多的去讲述这些事情。如果一次都说完的话文章就太长了，而且只用文字描述的话，部分内容可能无法很好的表述出来，那么读起来就略显干涩容易烦躁。所以就把这部分单独拿出来说一说。
当然还有其他的测试方式，比如说使用 Karma、NightWatch 等工具或框架来进行测试和保证功能的完全。这里就只说一下本地调试方式好了，还在开发阶段使用调试方式来修改、验证功能还是比较方便的。
OK，废话不多说直接进入正题。
01 - Link 命令
首先简单来了解一下 link 为何物
使用命令 npm help link 会弹出本地的帮助文档，我的英语水平不高就不来秀翻译了。
使用 link 的方式需要另一个项目的配合
文件夹结构如下
PROJECT
? ├─ cat-web-storage （需要发布的项目）
? └─ testModules （用于测试的项目）
npm link
首先需要创建本地 cat-web-storage?项目的 modules link
cd PROJECT\cat-web-storage
npm link完成后会输出一行这样的路径信息：
NODE_PATH\node_global\node_modules\cat-web-storage -> PROJECT\cat-web-storage??这时候就可以在文件夹 NODE_PATH\node_global\node_modules 中看到 cat-web-storage 的项目了。
但是这里和其他 node_modules 不一样的地方是 cat-web-storage 的文件夹居然有一个小箭头，也就是说生成的是一个快捷方式入口。
那么就可以理解为 npm link 命令为当前项目创建了 node_global modules 的快捷方式入口。
npm link?module
接下来在 testModules 项目中使用 cat-web-storage link
cd PROJECT\testModules
npm link cat-web-storage完成后发现会输出这样一个路径
PROJECT\testModules\node_modules\cat-web-storage -> NODE_PATH\node_global\node_modules\cat-web-storage -> PROJECT\cat-web-storage??哇！好长啊！
这里我可以简单解释一下：
项目的 node_modules 里的 cat-web-storage 是来自 node_global modules 里的cat-web-storage 的快捷方式，node_global modules 里的 cat-web-storage 的快捷方式是来自 cat-web-storage。
你等会儿你等会儿，我感觉有点乱。让我捋一捋……这怎么感觉像俄罗斯套娃？
就在这时候我沉思了一会的脑海里出现了一个大胆的想法。（赶快收起你的想法！！！）
假设我这个 testModules 也是一个 要发布的 package……（禁止套娃！！！）
02 - 启动错误
现在赶紧进行下一步，在 testModules 项目中添加如下代码
main.js 文件
import cws from 'cat-web-storage'
Vue.use(cws)App.vue
mounted () {
? ? this.$sessionStorage.set('key', 666);
}
然后启动 testModules? 项目，这时候你有大概率会报错?
ERROR? Failed to compile with 1 errors
? Module build failed (from ./node_modules/eslint-loader/index.js):
? Error: No ESLint configuration found in PROJECT\cat-web-storage\dist.（小朋友你是否有很多问号？）
看到这屏幕里带着鲜红颜色的字符你的眉头微微一皱：“为什么 install 下来的代码可以正常使用，反而本地用 link 就出问题了呢？”（嗬~哈~！砸！哇！撸！多！）
多年的经验就像条件反射一样在大脑的深处提醒着你这些鲜红色的字符来路并不是太简单，当你决定与它纠缠一番时定睛一看 Error: No ESLint configuration found ，接着嘴角露出一丝不易察觉的笑意，随即心中大喜“原来是 ESLint 的配置问题，小 case !”。心里那份与BUG战斗到底的紧张和急迫感瞬间一扫而去。
短暂的思考过后你还是觉得对待这样鲜红的字符还是要有一些仪式感，即决定还是给它一些面子。你正襟危坐而右手缓缓离开鼠标，双手置于键盘之上，气定神闲仿若置身于无比自信的光芒之中，键盘上的每一个按键都好似散发着熠熠光辉。
“噼里啪啦噼里啪啦噼里啪啦~”
（欧拉欧拉欧拉欧拉欧拉欧拉欧拉~）
（木大木大木大木大木大木大木大~）
专注而忘我，手指的每一次触击按键都像是对代码的灵魂进行锤炼。片刻之后，敲击声不再响起，眼里迸发出炽热而坚定的目光！这时的你没有半点迟疑，快速而又行云流水般的在命令行里敲下 npm run serve 随着 “啪” 的一声巨响而结束。
命令行开始变得躁动不安，字符不断的快速跳动和变更，光标亦像充满了能量一般疯狂的闪烁着。是代码被注入了灵魂吗？这跳动的字符，不断向上的百分比数值，仿佛这灵魂就要苏醒，仿佛这代码就要拥有了生命！
97%……98%……99%！！！希望的曙光就在前方，即将迎接朝阳沐浴晨光，这1%近在咫尺又好似在遥远的地方，黑暗中的无助彷徨就要变得不再迷茫！
啊！这是……？初升的太阳，那一抹红色如此的鲜亮！
ERROR? Failed to compile with 1 errors
? Module build failed (from ./node_modules/eslint-loader/index.js):
? Error: No ESLint configuration found in PROJECT\cat-web-storage\dist.（恭喜获得成就：梅开二度）吉良吉影给你点赞！ 一顿操作猛如虎，定睛一看原地杵。
这时候千万不要慌，也千万不要看到是 Error: No ESLint configuration found 就认为问题出在 ESLint 的配置上。
这里主要是涉及到了 webpack 处理模块导入的机制上。webpack 配置中加入如下代码即可解决。
// vue-cli 3.0+
// webpack 4.0+
chainWebpack: config => {
? ? config.resolve.symlinks(false);
}如果只想解决问题，不想深入了解原因的可以跳过下面这部分。
官网文档解释：
resolve.symlinks 参数类型为 boolean，默认为 true。 是否将 link 解析到他的 link 位置，默认启用。 启用时，符号链接(symlink)的资源，将解析为其真实路径，而不是其符号链接(symlink)的位置。 注意：当使用符号链接 package 包工具时（如 npm link），可能会导致模块解析失败。
对解释还是不太理解的话，我们可以来做个实验，实验步骤如下：
先将 PROJECT\testModules 的 node_modules\cat-web-storage 更名为 cat-web-storage1。
然后再将 PROJECT\cat-web-storage 整个项目复制到 PROJECT\testModules 的 node_modules 里。
也就是说现在我们在 PROJECT\testModules\node_modules 里有两个版本的 cat-web-storage，link 版的 cat-web-storage 和 完全版的 cat-web-storage。
这时我们可以通过对 cat-web-storage 文件名修改切来换不同的版本，然后这时我们就可以在 main.js 里看到 不同版本的 import module 的路径的变化。
link 版
完全版
由此就可以得出 resolve.symlinks 是告知 webpack 应该如何处理 link 文件路径方式的配置。
简单来说就是：
启用时?以 link 的真实路径为准。
不启用时?以 link 所在文件路径为准。
当这个 link 是在 node_modules 下时：
如果 symlinks 为 true 则表示该文件是使用真实路径所以并不属于 node_modules ，所以 webpack 在编译时不会将其加入一起构建。
如果 symlinks 为 false 时是以当前 link 所在文件夹路径为准，cat-web-storage link 是在 node_modules 下，所以 webpack 在编译时会将其加入一起构建。
03 - 测试与调试
还记得??npm publish package 发布流程 04 - package.js 改造 一节中的说明提到的。
如果要将包变得与众多开源 npm module 一样的话，那么就需要对 package.js 进行改造了。
package.js 中需要更改/添加以下配置信息
? main 变更以 dist/ 为入口的 index.js 文件
? module 以 dist/ 为入口的功能模块文件
但是如果想要使用 debugger 调试代码的话，这部分就需要更改为指向源码 src 而非编译后的 dist。
module: dist/index.js -> module: src/index.js
main: dist/index.js -> main: src/index.js这时候再次启动 testModules 项目，就可以对 cat-web-storage 进行愉快的调试和修改处理了，不再需要每次都 npm build?cat-web-storage 了。
如果你要问 module 和 main 有什么区别的话，我只能说在我实际的调试过程中发现webpack 对 module 的调用优先于对 main 的调用，如果 module 找不到则会使用 main，否则输出错误。
最后
- 有些问题是确实是和错误提示没有太大关系。
- 官方文档是个好东西，但文档内容不会穷举所有例子和场景，有时感觉会帮不上忙。
- 踩坑了不可怕，就怕没有正视它。穷追不舍的探索过程会让你印象深刻也更了解它。
版权声明：
本文版权属于作者 林小帅，未经授权不得转载及二次修改。
转载或合作请在后台留言及联系方式。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。