什么是脚手架?
脚手架本质是一个操作系统的客户端,它通过命令行执行,就比如:
vue create vue-test-app
上面这条命令由3个部分组成:
- 主命令:vue
- command:create
- command的param:vue-test-app
脚手架的执行原理
脚手架的执行原理如下:
- 在终端输入vue create vue-test-app
- 终端解析出vue命令
- 终端在环境变量中找到vue命令
- 最终根据vue命令链接到实际文件vue.js
- 终端利用node执行vue.js
- vue.js解析command/options
- vue.js执行command
- 执行完毕,退出执行
脚手架的实现原理
为什么全局安装@vue/cli
后会添加的命令为vue
?
首先我们通过which vue
找到vue
的目录/usr/local/bin/vue
,然后进入到/usr/local/bin
目录下,查看下面所有内容,其中有一条这样的链接vue -> ../lib/node_modules/@vue/cli/bin/vue.js
,vue
软连接到全局安装目录,去执行vue.js
,这种绑定关系是在那确定的呢?我们进入到../lib/node_modules/@vue/cli/
,查看package.json
,我们看到"bin": { "vue": "bin/vue.js" },
,这个bin
当中配置的就是我们在操作系统中安装完成后软连接的名称以及指向的实际文件
全局安装@vue/cli
时发生了什么?
npm install -g @vue/cli
首先npm把我们当前的包下载到node_modules
目录里面,如果是全局安装的node
,它可能存在/uer/lib/
目录下,当把这个包完全下载完毕之后,它会去解析package.json
里面的bin
,如果说bin
下面有配置,它就会在我们node
安装目录下的bin
目录里面创建一个软连接.
执行vue
命令时发生了什么?为什么vue
指向了js
文件,我们却可以直接通过vue
命令去执行它?
第一个问题:执行vue
的时候,我们操作系统会通过which vue
去找到bin
目录下的文件执行,也就是说去环境变量中找vue
是否被注册,注册了就执行.
第二个问题:因为在文件上方加入了!/usr/bin/env node
环境变量,这个环境变量可以让我们通过固定的命名去对它进行执行
扩展一下,下面两种写法的区别:
#!/usr/bin/env node
#!/usr/bin/node
第一种是在环境变量中查找node
第二种是直接执行/usr/bin/
目录下的node
脚手架的作用
开发脚手架的核心目标是: 提升前端研发效能
核心价值
- 自动化:项目重复代码拷贝/git操作/发布上线操作
- 标准化:项目创建/git flow/发布流程/回滚流程
- 数据化:研发过程系统化、数据化,使得研发过程可量化
脚手架开发难点解析
- 分包:将复杂的系统拆分成若干个模块
- 命令注册:
vue create
vue add
vue invoke
- 参数解析:
- options全称:
--version
、--help
- options简写:
-V
、-h
- 带params的options: -path xxxx
- options全称:
- 帮助文档
- 命令行交互
- 日志打印
- 命令行文字变色
- 网络通信:HTTP/WebSocket
- 文件处理
等等…
脚手架本地link标准流程
链接本地脚手架:
cd your-cli-dir
npm link
链接本地库文件:
cd your-cli-dir
npm link
cd your-cli-dir
npm link your-lib
取消链接本地库文件:
cd your-cli-dir
npm unlink
cd your-cli-dir
# link存在
npm unlink your-lib
# link不存在
rm -rf node_modules
npm install -S your-lib
理解npm link
:
npm link your-lib
: 将当前项目中的node_modules
下指定的库文件链接到node
全局node_modules
下的库文件npm link
: 将当前项目链接到node
全局node_modules
中作为一个库文件,并解析bin
配置创建可执行文件
理解npm unlink
:
npm unlink
: 将当前项目从node
全局node_modules
中移除npm unlink your-lib
: 将当前项目中的库文件依赖移除
原生脚手架开发痛点分析
- 痛点一:重复操作
- 多Package本地link
- 多Package依赖安装
- 多Package单元测试
- 多Package代码提交
- 多Package代码发布
- 痛点二:版本一致性问题
- 发布时版本一致性
- 发布后相互依赖版本升级
分析可痛点,那么就会有解决办法,那就是通过Lerna来管理多Package。