🎉 husky-rs： Rust 版 Git Hooks 工具

[purplemystic]

husky-rs

https://crates.io/crates/husky-rs

https://github.com/pplmx/husky-rs

[ShaunHu]

优秀阿

[purplemystic]

@ShaunHu Try it :)

[shakukansp]

感觉这玩意跑多久取决于跑的命令……而不是本身用什么写

[RangerWolf]

感觉楼上两个人的头像的风格跟 op 的风格是一样的，你们是托么？

ps: 并没有贬低 op 的意思，只是好奇~ 另外我也很菜，不知道 git hooks 是干啥的

[zsh2517]

@RangerWolf #4 git hook 是位于 .git/hooks 里面的东西，用来定义 git 发生某些行为（如 commit ）时（/前/后）执行一系列命令的配置工具。

常见的比如提交前格式化、跑单测和 lint 、生成提交信息等。

husky 是一个独立于 git 的、管理 git hook 配置的工具（ git hook 本身好像是不能提交到代码仓库的，如果项目内想共享一些 git hook 配置就需要 husky 一类的工具）

[zsh2517@VM-20-7-ubuntu|~/workSpace/hexo-test/.git/hooks|2.7.0p0|3.10.3] ‹master› »»»» ls
applypatch-msg.sample* post-update.sample* pre-merge-commit.sample* pre-rebase.sample*
commit-msg.sample* pre-applypatch.sample* prepare-commit-msg.sample* pre-receive.sample*
fsmonitor-watchman.sample* pre-commit.sample* pre-push.sample* update.sample*

[purplemystic]

@RangerWolf 不是哒

[purplemystic]

@shakukansp 不是解决快慢的问题, 主要是想要一个像 husky 的功能, 就是其他人 clone 项目后, 一定会被执行到的 hooks, pre-commit 依赖使用者主动去 pre-commit install, husky-rs 利用了 rust 的 build.rs 功能, 只要引用这个库, 使用者使用时, 就一定会将 hooks 加载到本地.git

[purplemystic]

@zsh2517 husky 其实依赖于 node 生态

[lisongeee]

可能我接触的项目较少

我发现只有 前端 项目会用 git-hooks ，因为前端项目的创建脚手架基本都会一键配置好

接触的 java/kotlin/python 都没有

[jqtmviyu]

@lisongeee #9

有些人配置 eslint 不装, Prettier 不装. 说不定还开保存自动格式化.

一改一大片, history 全乱了, 头疼.

特别还有什么换行, 分号 两个空格, 4 个空格之类的.

不过如果把 hooks 放在 git 服务器那边, 应该就没本地的这些事了.

[purplemystic]

@lisongeee 所以我觉得前端的 husky 就很好, 它于 npm 生态绑定, 你只要运行(install/build/test)这个项目, 那么项目已经设置的 hooks 必定被执行, 项目开发者的最初定的规则, 后来者必定强制执行, 这样就有了一个很多统一性

我实现的这个 husky-rs, 也期望在 rust 的 cargo 下实现类似的效果

[purplemystic]

@purplemystic #11 "很多统一性" ==> "很好的统一性"

[purplemystic]

@lisongeee 为什么只有前端会用呢? 因为其他语言类似工具集成的都不是很好.
你会发现很多其他语言的开源项目, 都会使用 pre-commit.com 虽然没有 husky 集成的那么紧密, 但是无奈只有这一个方案
总结: 大家(尤其是更大开源项目)是有 git hooks 需求的, 只不过前端的方案最好(愚见), 所以使用更广泛; 其他语言的开源项目, 退而求其次, 通常会使用 pre-commit

[purplemystic]

@purplemystic #13 "更大开源项目" ==> "很多开源项目"

[lisongeee]

#11

我现在已经不用 husky 了，它太过底层化，会出现一些配置问题

我现在用的 https://github.com/toplenboren/simple-git-hooks

同时它也是 vue 源码管理在使用的 https://github.com/vuejs/core/blob/29de6f8b0bb1a604f247b0712daac29e93aa6f3e/package.json#L45

---

#13

我觉得主要是前端有被广泛使用的 eslint/prettier/stylelint 这类代码工具，并且它们自带 --fix

其他语言基本就没有这种东西，也没有形成一个使用的基本意识

[lisongeee]

@jqtmviyu

> 有些人配置 eslint 不装, Prettier 不装. 说不定还开保存自动格式化.

呃呃，跟这个有啥关系，eslint/prettier 以及它们的 check/fix 都是直接声明在 package.json 里的

别人 git clone xxx 然后 pnpm install 就啥都初始化好了

后续就算你修改的任意 commit 全部都会走 check/fix 了，自动格式化和自动修复都会全走一遍

跟编辑器装什么代码插件使用什么代码风格完全没有任何关系，就算有在后续 commit 的时候也会被自动修正回来

[purplemystic]

@lisongeee #15 是的

[jqtmviyu]

@lisongeee #16 如果每位项目参考者把 eslint/prettier 插件都装上, 让项目里的配置文件生效, 不就没强制 hooks 这事了. 我的意思先有的 eslint/prettier 插件的这些尝试解决格式化的方案, 然而并不能强制每个人都执行, 才有的 hook 检查和处理. 而且就算有了 hooks 检查, 那也是发生在提交时了, 插件在编辑时就能预览了.

[lisongeee]

@jqtmviyu

> 如果每位项目参考者把 eslint/prettier 插件都装上, 让项目里的配置文件生效, 不就没强制 hooks 这事了

想法很没好，但是不可能的，就算装上也有版本差异，ide/vscode 自己也有版本差异，最好的方式就是直接作为项目依赖安装，和编辑器无关，有的人编辑器插件都懒得用或者装都装不明白，只会 npm i ，只有集成到项目里才是最好的方式