docs: update issue 124

toFrankie · Mar 17, 2024 · 0f3606b · 0f3606b
1 parent 14d158d
commit 0f3606b
Showing 1 changed file with 38 additions and 25 deletions.
diff --git a/archives/2023/124.md b/archives/2023/124.md
@@ -3,51 +3,59 @@ title: 使 Prettier 一键格式化 WXSS（下集）
 number: '#124'
 link: 'https://github.com/toFrankie/blog/issues/124'
 created_at: '2023-02-25 21:15:21'
-updated_at: '2023-12-11 18:02:50'
+updated_at: '2024-03-17 17:19:36'
 labels:
   - 编码规范
   - 小程序
-  - '2020'
   - 部分废弃
+  - '2020'
 ---
-> 本文将会结合 ESLint、Prettier、husky、lint-stage 等工具使得项目一键化操作，减少在格式化、代码检查等操作上浪费时间，因为大前端真的太多东西学了，不学会“偷懒”的话，我们就要落后更多了。
->
-> 本系列文章的示例 Demo 在这里  [GitHub: wechat_applet_demo](https://github.com/toFrankie/wechat_applet_demo.git)。
->
-> 分为三篇文章介绍：
-> * [使 Prettier 一键格式化 WXSS（上集）](https://github.com/toFrankie/blog/issues/123)
-> * [使 Prettier 一键格式化 WXSS（下集）](https://github.com/toFrankie/blog/issues/124)
-> * [使 Prettier 一键格式化 WXSS（结局篇）](https://github.com/toFrankie/blog/issues/125)
->
-> 扩展篇
-> * [Git Commit 规范](https://github.com/toFrankie/blog/issues/101)
+## 写在前面
+
+最近，在处理部门前端项目由 SVN 迁移 Git 的事情。由于历史代码在此之前并没有引入类似 [ESLint](http://eslint.cn/)、[Prettier](https://prettier.io/) 的代码检查或者格式约束等工具。
+
+目前部门仅剩我一人维护这十几个小程序、H5 前端项目。现在只要接触以前没有经手的项目，就头疼不想改，很无奈，谁让我是一个打工人呢！
+
+本文将会结合 ESLint、Prettier、husky、lint-stage 展开介绍，旨在在代码格式化、代码检查上减少时间浪费。
+
+完整示例：[wechat_applet_demo](https://github.com/toFrankie/wechat_applet_demo.git)
+
+共三篇：
 
-上一篇[文章](https://github.com/toFrankie/blog/issues/123)介绍了如何一键格式化 `wxss` 文件。
+- [使 Prettier 一键格式化 WXSS（上集）](https://github.com/toFrankie/blog/issues/123)
+- [使 Prettier 一键格式化 WXSS（下集）](https://github.com/toFrankie/blog/issues/124)
+- [使 Prettier 一键格式化 WXSS（结局篇）](https://github.com/toFrankie/blog/issues/125)
 
-今天介绍利用 Git Hooks 钩子实现提交代码自动执行此前的 ESLint、Prettier 命令，以保证我们提交的代码是不丑的。
+扩展篇：
+
+- [Git Commit 规范](https://github.com/toFrankie/blog/issues/101)
+
+[上一篇](https://github.com/toFrankie/blog/issues/123)介绍了如何一键格式化 `wxss` 文件。今天介绍利用 Git Hooks 钩子实现提交代码自动执行此前的 ESLint、Prettier 命令，以保证我们提交的代码是不丑的。
+
+## Git 钩子
 
-### 一、Git 钩子
 Git 提供了一些钩子，能在特定的重要操作发生时触发自定义脚本。
 
 当我们执行 `git init` 初始化一个 Git 版本库时，Git 会默认在 `.git/hooks` 目录中放置一些示例脚本（Shell 脚本）。这些示例脚本都是以 `.sample` 结尾，如果你想启用它们，得先移除这个后缀。
 
 把一个正确命名（不带扩展名）且可执行的文件放入 `.git/hooks` 目录下，即可激活该钩子脚本。 这样一来，它就能被 Git 调用。
 
-### 二、常用钩子
+## 常用钩子
 
 * **pre-commit**
 该钩子在键入提交信息前运行。 它用于检查即将提交的快照，例如，检查是否有所遗漏，确保测试运行，以及核查代码。 如果该钩子以非零值退出，Git 将放弃此次提交，不过你可以用 `git commit --no-verify` 来绕过这个环节。 你可以利用该钩子，来检查代码风格是否一致、尾随空白字符是否存在，或新方法的文档是否适当等等。
 
 
-### 三、husky
+## husky
 
 [husky](https://github.com/typicode/husky#readme) 是一个为 Git 客户端增加 `hook` 的工具。当其安装到所在仓库时，它会自动在 `.git/hooks` 增加相应的钩子实现在 `pre-commit` 阶段就执行一系列保证每一个 `commit` 的正确性。
 
 当然，`pre-commit` 阶段执行的命令，当然要保证其速度不要太慢，每次 `commit` 都等很久也不是好的体验。
 
-##### 1. 安装 npm-run-all
+### 安装 npm-run-all
 
 它用于同步或者并行执行 npm script 脚本。
+
 ```shell
 $ yarn add --dev [email protected]
 ```
@@ -60,6 +68,7 @@ $ yarn add --dev [email protected]
   }
 }
 ```
+
 这行命令做了什么：首先并行执行 `prettier:wxss:acss` 和 `prettier:fix` 两个命令，等到执行完之后才会执行 `eslint:fix` 命令。
 
 * `npm-run-all -p` 表示并行操作。
@@ -87,7 +96,9 @@ $ yarn add --dev [email protected]
   }
 }
 ```
-##### 2. 安装 husky
+
+### 安装 husky
+
 ```shell
 $ yarn add --dev [email protected]
 ```
@@ -106,11 +117,13 @@ $ yarn add --dev [email protected]
   }
 }
 ```
-##### 3. 看效果
+### 验证
+
 我们随便修改一个文件，然后进行提交。如图，可以看到是按照预期执行的，好了。
+
 ![](https://upload-images.jianshu.io/upload_images/5128488-284d03ac44d48a62.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
 
-### 四、lint-staged
+## lint-staged
 
 看到上面的结果，似乎一切顺利。但没有完...
 
@@ -160,7 +173,7 @@ module.exports = {
 
 `lint-staged` 采用的是 `glob` 匹配模式。从上面的配置中，通过匹配不同的文件类型执行相应的操作。
 
-*关于 `lint-staged` 相关使用说明，建议查看[官方文档](https://github.com/okonet/lint-staged)或者较瘦的这篇[文章](https://www.cnblogs.com/jiaoshou/p/12250278.html)，我就不再详说。
+关于 `lint-staged` 相关使用说明，建议查看[官方文档](https://github.com/okonet/lint-staged)或者较瘦的这篇[文章](https://www.cnblogs.com/jiaoshou/p/12250278.html)，我就不再详说。
 
 > 不知道有没有人好奇，上面 `lint-staged` 配置文件中，我在匹配 `.wxss` 文件时采用的是函数形式。
 >
@@ -179,11 +192,11 @@ module.exports = {
 
 > 有解决方案了，快去看[结局篇](https://www.jianshu.com/p/553cef04e262)。
 
-### 至此
+## 最后
 
 到这里基本就结束了，但可能还会加入 Commit Message 提交说明的规范，因为一个清晰明了的提交说明，可以让人很清楚本次代码提交的目的或者解决了什么具体问题。目前使用最广的应该是 Angular 规范了，比较合理和系统化，而且有配套的工具。
 
-> 补充了一篇关于 Git Commit Message 规范的文章  [这里](https://github.com/toFrankie/blog/issues/101)。
+> 补充了一篇关于 Git Commit Message 规范的文章[这里](https://github.com/toFrankie/blog/issues/101)。
 
 若有不足之处，欢迎留言指正。