前端架构: 本地调试脚手架的2种方式_如何启动脚手架调试-优快云博客

假定脚手架名称是 xxx

1 ）方式1

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
- 注意 -> 表示软链的意思
通过以上两次软链，就可以直接调试当前脚手架项目，做到随时修改，随时使用

假设有两个平行的项目 x1 和 x2，在x1中需要引入x2包
x1的目录结构
```
x1
├── package.json
├── bin
    └── index.js
```
- 在package.json 中的 main 属性配置为 bin/index.js
x2的目录结构
```
x2
├── package.json
├── lib
    └── index.js
```
- 在这里的 lib/index.js中有一个方法
```
module.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 上面
再次尝试，首先在 x2 中执行 $ npm link
- 让这个包在全局的 node_modules 目录中创建一个软链到当前开发项目 x2 的目录上
- 这时候，全局环境下的 node_modules 下就可以找到 x2 了
- 再次回到 x1 根目录 x1/ 下执行 $ npm link x2
到这个时候，环境基本已准备好了，可以在x1中正常引入x2了，在x1中的 package.json 中
```
{
  "dependencies": {
    "x2": "^1.0.0"
  }
}
```

回到 x1 中，进入 bin/index.js 编写

#!/usr/bin/env node

const lib = require('x2');
const { sum } = lib;
const result = sum(1 + 2)

console.log('result: ', result)

使用这种方式，基于 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
注意，以上的方式，不修改项目源码，而是修改本地环境，不会因为后期忘记修改回来或误操作引发bug
修改源码的方式
- 之前会用 npm 安装本地包，之后 dependencies 中，出现 "bar": "file:foo/bar" 这类的形式
- 这种，会导致后期上线非常的不方便，而且不注意就会引发问题
这种不修改源码(包括package中的配置)而修改本地环境的方式，可以作为一种最佳实践方式