①. git权限:
a. 场景:
(1). 新公司或新项目,创建一个项目时,一般是以下两种方式:
a. 去git仓库拉取项目模板
b. 拷贝之前的项目
b. 痛点:
(1). git仓库有推动权限的人员,可能会修改模板仓库
c. 解决:
(1). 从git上拉取最新模板后,切断和远程仓库的关联(可参考vue-cli)
②. 规范:
a. 痛点:
(1). 项目结构不同的团队、技术栈的项目结构不统一、不规范,代码交付质量不可控
(2). 提交commit没有规范,无法了解提交开发内容
b. 解决:
③. 更新:
a. 痛点:
(1). 拷贝过的项目无法获取最新的项目模板,可能会修复了一些问题
④. 定制化需求:
a. 痛点:
(1). 不能定制化一些需求,如初始化一个h5、web app、PC不同的场景
(2). 前端项目类型多,不同项目不同配置,管理成本高.
b. 解决:
(1). 可控性高,需要满足团队特定需求的开发.
(2). 根据配置信息生成配置文件(可参考vue-cli)
①. 功能:
a. 脚手架是一套命令集,不只用来创建项目.
b. 解耦 - 脚手架与模板分离:
(1). 脚手架负责构建流程,通过命令行与用户交互,获取项目信息
(2). 脚手架需要检测模板的版本是否有更新,支持模板的删除与新建
(3). 模板负责统一项目结构、工作流程、依赖项管理
②. 作用:
a. 减少重复工作,不需要复制其它项目再删除无关代码,或从零创建一个项目和文件.
b. 根据交互动态生成项目结构和配置文件.
①. 构建:
a. 提供本地构建功能
b. 接管发布构建
②. 质量:
a. 自动化测试
b. Eslint校验
③. 模板:
a. 创建模板
b. 创建区块
④. 工具合集:
a. 其他可以内置的工具类
(1). 构建:
①. 小团队构建流程:
a. 在一套或多套模板中使用webpack或rollup构建工具,配置多个文件,如.env.production、.env.development、.env.staging
b. 通过Shell脚本来构建项目
c. 进行部署,实现了简单、通用的CI/CD流程
②. 构建过程不可控:
a. 团队的开发成员都可以修改发布配置项
b. 误操作,如选择的是dev模式,没有对构建代码压缩混淆、没有注入一些全局统一方法等.
③. 优化:
a. 构建配置和项目模板分离:
(1). 将构建配置、过程从项目模板中抽离出来,统一使用CLI管理构建流程:
(2). 不再读取项目中的配置
(3). 通过CLI使用统一配置(每一类项目都可以自定义一套标准构建配置)进行构建.
b. 避免业务开发同学修改了错误配置而导致的生产问题.
(2). 质量:
①. 通用的自动化测试、常规的格式校验统一:
a. 如每个开发的习惯不同,导致ESLINT校验规则不同.
b. 同一个团队必须使用同一套代码校验规则最好.
②. 优化:
a. 将自动化测试、校验从项目中剥离,使用CLI接管,从而保证整个团队同一类项目代码格式的统一性.
(3). 模板:
①. 可以快速、便捷初始化一个项目或代码片段.
②. Cli工具产出最高、收益最明显的功能模块.
(4). 工具合集:
①. 通用的工具类:
a. 图片压缩(png压缩)、上传CDN等
b. 项目升级(如通用配置更新了,提供一键升级模板的功能)
c. 项目部署、发布npm包等操作
②. 其它一些重复性的操作
(1). 初始化package.json文件:
yarn init
(2). 在package.json中,新增bin属性:
{
"name": "cli",
"main": "index.js",
"bin": {
"gl-cli": "./index.js" // gl-cli表示脚手架的名称
}
}
(3). 根目录下新增cli.js文件:
#!/usr/bin/env node
// Node CLI 应用入口文件必须要有这样的文件头,用于指定脚本的解释程序
console.log('gl-cli working!')
注:
①. Linux或maxOS,需要修改此文件的读写权限为755:
chmod 755 cli.js
(4). 把本项目/应用链接到yarn全局缓存(链接到全局),只是方便开发调试:
yarn link // 在当前根目录执行,yarn unlink可卸载
注:
①. 检查当前yarn的bin位置:
a. yarn global bin => /Users/xxx/.yarn/bin => 有一个gl-cli执行命令
②. 检查当前 yarn 的 全局安装位置
a. yarn global dir => /Users/xxx/.config/yarn/global => 下面有一个link文件
(5). 测试执行本cli命令:
gl-cli