前端架构: 脚手架之包管理工具的案例对比及workspace特性的基本使用

1 ）使用或不使用包管理工具的对比

2 ）workspaces 的基本使用

在一个脚手架项目中，比如xyzcli项目中(之前一直用这个脚手架演示)创建workspaces 目录
- $ mkdir workspaces && cd workspaces
在 workspaces 目录中执行
- $ npm init -y
- 其实，在使用 npm init 的过程中，通过 $ npm init --help
- 可以看到 Options 中存在 [-w|--workspace <workspace-name> [-w|--workspace <workspace-name> ...]]
- 也就是 -w 的参数, 比如：$ npm init -w a -w b 默认一路回车
- 这样，就会在 workspaces 目录下新建了两个包：a 和 b，每个包中，都存在package.json，其name属性分别为 a 和 b
- 在 workspace/node_modules下生成a和b的两个软链
- 在 workspace/package.json 中，存在 workspaces 的配置
```
"workspaces": ["a","b"
]
```
好，现在结构基本搭建完成，现在我要在 workspaces 目录对a包进行安装依赖
- $ npm i vue -w a
- 这时候，a包中安装了 chalk 的依赖，但是a包中没有生成 node_modules 目录
- 在 workspaces 目录下的 node_modules 中安装了 chalk, 而 a 的 package.json 中的 dependencies 是 chalk
- 同时，b包中的package.json中是没有的
这是 workspace 非常有意思的特性，它把各个内层包的依赖抽象到了最外层来进行管理
这里借助了 commonjs 中对 node_moduels 查找的特性，如果当前查找不到，去上一层目录中去查找
由于此特性，可以通过最外层来管理依赖包，这样的好处是非常明显的

现在在a包中使用chalk, 在package.json中添加 "type": "module" 在 a/index.js 中编写

import  chalk from 'chalk';export default {print() {console.log(chalk.red('Hello workspace'))}
}

现在继续修改 a/package.json 中的 name属性，修改为：“@somegroup/a”
这时候，a包就会在后续发布中，自动在 somegroup 分组中了，这个 somegroup 可以是自己起的任意组名
好现在在workspaces目录中新增一个具有cli功能的包，比如就叫做 cli 这个脚手架包
$ npm init -w cli 一路回车, 创建了 cli 这个脚手架包
将 cli 包的 package.json 目录中的name属性改成和a包同组，如："name": "@somegroup/cli"
同时在 workspaces/cli 的package.json中添加 bin 属性
```
{"bin": {"cli": "bin/cli.mjs"}
}
```
因为这时候 cli 脚手架包的 name 不是在一开始创建的，而是一路回车之后，要确定和a同组的，需要执行下 $ npm i -ws 来更新下分组
- 这时候可以看到 workspaces/node_modules/@somegroup/下存在 a 和 cli 两个软链
- 同时，可以删除 workspaces/node_modules/cli 这个软链
这时候，想要在 cli 这个脚手架包中引用 a包来调试，需要在 workspaces 目录下执行
- $ npm i @somegroup/a -w cli
- 这时候，会在 cli 脚手架目录中添加了 @somegroup/a 这个 dependencies

新建 bin/cli.mjs 编写

#!/usr/bin/env nodeimport * as a from '@somegroup/a'const { print } = a.default;
print();

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://xiahunao.cn/news/2815859.html

如若内容造成侵权/违法违规/事实不符，请联系瞎胡闹网进行投诉反馈，一经查实，立即删除！