一、 调试简单的脚手架方式
假定脚手架名称是 xxx
1 )方式1
- 在xxx脚手架项目目录的上一级,执行
npm i -g xxx
- 这时候,就可以本地调试脚手架,在前文中已经说明软链的作用
- 参考:https://blog.csdn.net/Tyro_java/article/details/136102674
- 这种方式,可以用到已经发版上线的脚手架项目中
2 )方式2
- 在未发过版的脚手架项目的根目录中,也就是 xxx/ 下执行 $
npm link
也可以调试本地脚手架 - 这时候,在当前命令的日志输出中,就会出现两个软链
- 将当前使用的node目录下的 bin/xxx -> 当前node所使用的node_modules中的 xxx/bin/index.js
- 注意,这个要确保package.json 中配置的 bin 属性是 bin/index.js
- 再将当前node所使用的node_modules中的 xxx -> 当前脚手架的项目目录 xxx
- 注意 -> 表示软链的意思
- 将当前使用的node目录下的 bin/xxx -> 当前node所使用的node_modules中的 xxx/bin/index.js
- 通过以上两次软链,就可以直接调试当前脚手架项目,做到随时修改,随时使用
二、调试含有分包的脚手架项目
-
假设有两个平行的项目 x1 和 x2,在x1中需要引入x2包
-
x1的目录结构
treex1 ├── package.json ├── bin └── index.js
- 在package.json 中的 main 属性配置为 bin/index.js
-
x2的目录结构
treex2 ├── package.json ├── lib └── index.js
-
在这里的 lib/index.js中有一个方法
jsmodule.exports = { sum (a, b) { return a + b } }
-
在 package.json 中的配置
- version 配置为 1.0.0
- main 配置为 lib/index.js (注意,这个是x1引用x2的关键)
-
-
如果想要在 x1 中自动连接 x2,尝试
- 在x1目录的上一级目录执行 $
npm link x2
- 这种方式,显然是失败的
- 因为 x2 包还没有发布到 npm 上面
- 在x1目录的上一级目录执行 $
-
再次尝试,首先在 x2 中执行 $
npm link
- 让这个包在全局的 node_modules 目录中创建一个软链到当前开发项目 x2 的目录上
- 这时候,全局环境下的 node_modules 下就可以找到 x2 了
- 再次回到 x1 根目录 x1/ 下执行 $
npm link x2
-
到这个时候,环境基本已准备好了,可以在x1中正常引入x2了,在x1中的 package.json 中
js{ "dependencies": { "x2": "^1.0.0" } }
-
回到 x1 中,进入 bin/index.js 编写
js#!/usr/bin/env node const lib = require('x2'); const { sum } = lib; const result = sum(1 + 2) console.log('result: ', result)
- 验证,在 x1/ 下执行 $
node bin/index.js
- 输出 result: 3
- 或者执行 $
x1
来验证
- 验证,在 x1/ 下执行 $
-
使用这种方式,基于 x1 来调试 x2,调试完成 x2 就可以准备上线了
-
上线完成后,x1 就可以重新下载 x2 作为依赖了,但是这个时候,可能会出现一些问题
- 如果直接在 x1/ 下执行 $
npm i
这时候下载的 x2 会被下载到 全局 node_modules 目录下 - 而项目本地的node_modules 没有写的权限
- 因为之前存在 link 的行为,而 link 后会在全局 node_modules 下创建软链
- 这时候,需要执行
- $
npm unlink x2
- 注意这里,如果失败的话,尝试: 先执行一次 link x2, 之后再重新 unlink x2
- $
npm remove -g x2
- $
npm i x2 -S
- $
- 如果直接在 x1/ 下执行 $
-
注意,以上的方式,不修改项目源码,而是修改本地环境,不会因为后期忘记修改回来或误操作引发bug
-
修改源码的方式
- 之前会用 npm 安装本地包,之后 dependencies 中,出现
"bar": "file:foo/bar"
这类的形式 - 这种,会导致后期上线非常的不方便,而且不注意就会引发问题
- 之前会用 npm 安装本地包,之后 dependencies 中,出现
-
这种不修改源码(包括package中的配置)而修改本地环境的方式,可以作为一种最佳实践方式