第八期: 前端九条启发分享
一、设置 git commit 的校验 (husky:^5版本之前配置与这里不一样)
在个别状况下, 咱们每次执行 git commit -m'提交信息' 的时候, 会触发针对 commit 信息的校验以及代码格调的校验, 如果没通过校验会导致 commit 失败, 那么这些校验是如何退出到我的项目中的那?
大部分时候增加针对 commit 的校验咱们会应用 husky 这个包, 让咱们来装置一下它:
yarn add husky -D 在 packgae.json 中增加上面内容, 这里是初始化.husky/ 目录并指定该目录为 git hooks 所在的目录, 所谓的 git hooks 能够了解为 git 的钩子函数, 比方 git add 执行之前, git commit之后等等生命周期的钩子函数, 而 git hooks 所在目录就是用来定义 git 各个生命周期须要执行的各种函数。
{
"scripts": {"prepare": "husky install"}
}第一步: 增加代码校验
接下来咱们在命令行执行:
yarn prepare
npx husky add .husky/pre-commit "npm run lint" 上述第二条命令定义了 pre-commit 这个生命周期执行npm run lint 这句命令。
在 packgae.json 中定义 lint 命令是应用 eslint 检测 src 文件夹里的文件, 当然啦检测什么文件都能够。
"scripts": {"lint": "eslint src"},第二步: 增加提交信息校验
校验 commit 信息咱们最简便的形式就是依赖 commitlint 这个包。
yarn add @commitlint/config-conventional @commitlint/cli -D 在根目录里新建 commitlint.config.js 并写入上面内容:
module.exports = {extends: ["@commitlint/config-conventional"]
};增加校验 commit 的 hook:
npx husky add .husky/commit-msg 'npx --no-install commitlint --edit"$1"' 下面命令的意思是创立一个commit-msg hook 的文件, 外面的内容是npx --no-install commitlint --edit "$1"。
commitlint命令来检测 $1 这个参数的值是否非法, 而 $1 就是咱们的git commit -m ${1}。
校验的规范
请查阅标准文档
这里我只列出最罕用的几个:
| 标准 | 应用形式 |
|---|---|
| docs | git commit -m"docs: 更新 xxx 文档" |
| feat | git commit -m"feat: 新增 xxx 模块" |
| fix | git commit -m"fix: 修复了上线的 xxxxbug" |
| style | git commit -m"style: 更新用户信息弹框的款式" |
| test | git commit -m"test: 批改增加用户按钮的测试用例" |
与你我的项目里配置不一样?
有的同学可能发现了, 我这里的写法可能与你我的项目里的写法不统一, 你的我的项目可能是如下的写法:
{
"husky": {
"hooks": {
"pre-commit": "npm run test",
"commit-msg": "commitlint -e $HUSKY_GIT_PARAMS"
}
}
} 上述写法是 husky^6 版本之前的写法, 当初 husky 曾经更新到了 7 版本, 所以将来创立新我的项目可能不会再用这种写法配置了。
git 的 hook
git 官网形容 hooks
二、/// 这种正文的应用
咱们在 react 我的项目代码里会看到上面这种正文, 那么这种奇怪的正文是干么的那?
/// <reference types="react-scripts" /> 原来这种 /// <reference types="包" /> 的写法次要用在 .d.ts 文件外面, 作用是引入其余的 .d.ts 文件, 比方我须要用到一个 xxx.d.ts 文件, 然而这个并没有放在 node_modules/@types 外面, 所以并不会被零碎默认导入。
ts 官网给出的解释
三、举荐一款 react 疏导插件 guide
插件地址
个别网站第一次拜访的时候都会有个疏导操作, 应用 guide 就能够轻松实现, 让咱们一步步来配置:
yarn add byte-guide 这个插件的应用办法的中心思想是, 咱们以数组的模式传入一套配置, 找个配置外面有 要被挂载 的指标 dom, 以及显示的文案等信息, 而后每次点击下一步就能够顺次执行数组内的对象:
import Guide from "byte-guide";
export default function Home() {
const SEARCH = {
hotspot: true,
title: "搜寻组件",
selector: "#search",
placement: "top-left",
content: <div> 这个搜寻组件很厉害 </div>,
offset: {x: 20},
};
const TOTAL = {
title: "列表总数",
parent: "#search",
selector: "#total",
placement: "right",
content: "这里是列表总数。",
};
return (<div className={"org"}>
<div id={"search"}> 指标 1 </div>
<div id={"total"}> 指标 2 </div>
<Guide
lang="en"
localKey="uni-key"
className="my-guide"
steps={[SEARCH, TOTAL]}
onClose={() => {console.log("点击敞开");
}}
afterStepChange={(nextIndex, nextStep) => {console.log("点击下一步");
}}
/>
</div>
);
}次要属性的阐明
localKey: 咱们疏导组件的显示个别是只有用户第一次登录才显示, 或者是当用户点击了疏导的完结按钮就永远不显示了,guide将是否须要展现疏导组件的值贮存在Local Storage中, 所以这里定义了贮存的 key 名。placement定义了弹出框所在的地位, 比方顶端的元素咱们会抉择应用bottom之类的属性。offset尽管设置了placement然而不免地位不尽人意, 所以能够应用这个属性对疏导框进行地位的再调。
注意事项
组件内置了简略的国际化, 也就是当咱们不指定文案的时候, 他本人会依据传入的语言 英语 、 中文 、 日语 进行文案的扭转。
这个插件有 bug, 如果两个元素处于父元素的外部滚动状态时, 会呈现定位偏差十分多的问题, 所以如果你的疏导我的项目波及外部滚动的元素则不倡议应用这个插件。
四、eslint 7 版本之后能够正文
发现团队我的项目中难免会呈现一些 /* eslint-disable*/ 这种正文, 每次看到会尝试将其删除, 然而可能会引起一系列的连锁翻译, 这种状况下如果咱们应用的是eslint^7 版本及以上, 则能够增加正文, 阐明为什么这里必须应用/* eslint-disable*/。
// eslint-disable-next-line a-rule -- 这里的谬误无奈修复！ 下面的写法更加敌对, 因为毕竟这种禁止 eslint 检测的形式不举荐大家应用, 如果必须要应用也须要在初期就表明起因。
五、对立一个 index 文件导出的利与弊
比方咱们有很多的 工具办法 放在同一个文件夹下,a.js文件导出 a1, a2 等办法 咱们经常应用一个 index.js 文件进行对立的导出, 我的项目里会有很多如下的写法:
export * from './a';
export * from './b';
export * from './c';
export * from './d';
这种写法尽管看起来计较 ” 优雅 ” 然而有不少弊病存在, 这里咱们就列举一下:
1: 导出名字可能反复
这是个小问题因为会有 ts 报错提醒, 起因是 index.js 文件外面没有写出具体的办法名, 所以须要每次批改注意一下 index 文件是否报错。
2: 代码寻径麻烦
这点也就是对操作最不敌对的一点, 比方咱们在某个页面上有一个外界导入的办法, 咱们 mac 电脑的话点击 `c
ommand + 鼠标左键 就能够查到这个办法的出处, 然而往往只是寻径到了index.js`, 这里也没有具体的办法名称出现, 所以须要再次进到各个文件外面查问。
3: 扭转导出没有提醒
当咱们批改一个导出时没有提醒, 比方删掉一个导出办法, 批改一个导出办法的名称, 此时并不会在文件自身以及 index.js 文件种报错, 报错的中央是具体应用到这个办法的文件, 这就可能会疏忽到, 因为不启动我的项目间接 git push 也是能够测验通过的。
4: ts 类型二次推导
有时候会呈现你命名导出了一个办法函数, 然而 eslint 报错说 没有导出该成员, 然而当咱们进入到这个办法的文件夹里后, eslint 的报错就隐没了, 这种不好的体验都与这种写法无关。
六、svgr库转换svg 图片, filter:drop-shadow
xxx.svg这些文件是不好管制的, 咱们想动静的传入很多配置可能须要借助 svgr 这个库将 svg 图片 转换成 react 组件的模式, 通过上面的命令能够在命令行生成代码数据:
npx @svgr/cli --icon 图片的地址.svg
在命令行里生成必定是不能工程化的, 其实各种脚手架曾经内置了这个 svgr 库, 所以咱们其实如下形式就能够应用 组件模式的svg 图片啦。
import {ReactComponent as Logo} from "./logo.svg";
// ....
<Logo width={"30px"} style={{filter: "drop-shadow(red 20px 0)" }} /> filter: "drop-shadow(red 20px 0)"这句能够使 svg 变成红色, 对于它的细节我会单拿一篇文章去讲。
七、yarn resolutions 治理被多我的项目依赖的包
我的项目中会援用很多的 npm 包, 比方咱们我的项目外面依赖了 A 包, A 包 本身又依赖 ^3.1.5版本的 B 包, 咱们我的项目自身yarn add B 曾经装置了 ^3.0.5 版本的 B 包, 此时 B 包 其实是能够通用的, 齐全没必要援用两个版本。
并且如果打包的话因为咱们两处依赖的不同版本的 B 包 导致打包后体积的增大, 所以 yarn 提供了 resolutions 这个配置项, 咱们能够如下配置(package.json):
"resolutions": {"B": "^3.1.5"}举一个理论的例子
咱们创立一个新我的项目
npx create-react-app 项目名称进入到我的项目中
yarn list --depth=1列出我的项目的依赖, 并且只打印一级依赖即可, 咱们就以 workbox-build 为例:
咱们在外层 package.json 进行配置:
"resolutions": {"fs-extra": "^4.0.2"}此时执行 yarn 命令, 并且在此 yarn list --depth=1 打印:
下面的依赖关系曾经变动了, 不是仅仅在 workbox-build 包的上面了。
八、pnpm 代替 yarn lean 做包的治理
咱们常常应用 yarn + lean 这种形式治理子项目, 然而传输中 pnpm 更适宜做这个工作, 那么为什么说 pnpm 更适宜那?
yarn治理 node_modules 的机制会导致, A 包 依赖的 B 包, 那么 B 包 的文件地位会处于与 A 包 同级, 这就导致开发者尽管没有执行 yarn add B 然而我的项目中也能够引入import B from 'B', 这就为开发埋下拉隐患。
pnpm采纳的形式是, 将包对立治理, 单个我的项目的 node_modules 文件外面贮存的相似 软连贯 , 这样就不会呈现反复装置某个依赖的状况了, 并且也没必要将B 与 A 放在同一层级了, 也就不存在莫名其妙的引入 B 包的状况。
当咱们有很多子项目并且依赖越来越简单的时候, pnpm的劣势就显示进去了。
九、微前端的子利用, 如何独自启动
微前端利用外面都会有几个子项目, 这些子项目往往会依赖一个主我的项目 (壳工程), 主我的项目负责散发一些重复使用的资源, 比方react react-router 等等专用的依赖, 并且也会呈现主我的项目里的一些自定义的 utils 工具办法传递给 子项目。
因为存在泛滥须要主我的项目散发的资源那么就对子我的项目独自的运行制作了艰难, 咱们每次都要启动至多 主我的项目 + 子项目 , 并且想要看到残缺工程还须要启动其余的所有 子项目, 但咱们有什么方法只启动子我的项目本身那?
我这里的做法是利用申请的代理, 因为大部分微前端框架的原理是 每个子项目 都是一个 js 文件, 主利用启动后按需加载 子项目的 js 入口文件 , 那么咱们就能够拜访 线上测试环境 的地址, 而后找到 线上测试环境 的主利用拜访子利用的 url, 而后将这个url 代理其指向本地启动的 子项目 的地址即可。
这样做的益处就是能够让子项目齐全处于一个线上环境的主利用的上下文里, 并且不必启动其余子项目, 要留神子项目的 css 文件也要代理过去。
end
这次就是这样, 心愿与你一起提高。