前端架构: 本地调试脚手架的2种方式

一、 调试简单的脚手架方式

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

二、调试含有分包的脚手架项目

• 假设有两个平行的项目 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 nodeconst lib = require('x2');
  const { sum } = lib;
  const result = sum(1 + 2)console.log('result: ', result)
  

  • 验证，在 x1/ 下执行 $ node bin/index.js
    • 输出 result: 3
  • 或者执行 $ 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

• 注意，以上的方式，不修改项目源码，而是修改本地环境，不会因为后期忘记修改回来或误操作引发bug

• 修改源码的方式

  • 之前会用 npm 安装本地包，之后 dependencies 中，出现 "bar": "file:foo/bar" 这类的形式
  • 这种，会导致后期上线非常的不方便，而且不注意就会引发问题

• 这种不修改源码(包括package中的配置)而修改本地环境的方式，可以作为一种最佳实践方式