2021/04/16 に公開 1027 views

このエピソードについて

@potato4d が @pittanko_pta と @tatsuya.yamamoto に、 LINE として husky をスポンサリングするようになった経緯や、他のツールと比較しての husky の立ち位置、これからの UIT での活用方法について語りました。

LINE のスポンサリング状況

https://github.com/typicode/husky にも掲載されている

img

スポンサリングの経緯について

  • きっかけはLINEポイントクラブ

    • もともとコミット時にどの文脈で対応したのかわかりやすいよう、JIRAの番号を先頭につけることをしていた
    • これ自体はhuskyを使っておらず、お手製のgit-hookを使っていた
  • そこから時が流れて2021年1月…

    • 他プロジェクトの人その仕組みはどうやっているのかと聞かれる
      • そこから派生していろんなgit-hooks系の話になった
  • git hooks の手段について

  • husky v5の話が出て、使ってみたいということに

    • ただし、新しいライセンス形態の関係で、スポンサリングしないと使えないことがわかった
    • LINE としてスポンサリングすればいいのでは?ということになり、 @pittanko_pta が提案し、実現

pre-commit 系のツール比較

  • husky v4
    • package.jsonにgit hooks用のコマンドを書いておくと、nativeのgit hooksが実行されるときに呼び出してくれる。
    • 具体的な動きは、npm install時に.git/hooks配下にhusky用のshell scriptを設置してくれて、hook時にpackage.json内のコマンドを呼ぶ。
    • huskyがv5でMITじゃなくなったという点だけが盛り上がった気がしているが、v4 がdeprecatedになった訳ではない。
    • 実際、v5リリースの後にもv4のパッチアップデートがある。
  • husky v5
    • husky v5 は huskyの新しい方針に基づいて実装されたもので、v4と互換性が全くない。
    • 新しい方針はv4の改題を解消する、というもので、作者のブログで言及されている。
      • v4では.git/hooks配下に定義できるhook用のshell scriptをすべて設置していたので、パフォーマンスが悪い
      • huskyといえば自動インストールが楽ちんだが、package managerのキャッシュで旨く動かないケースがあったらしい
      • なので、v5以降では、hookごとにshell scriptを作成すること、インストール用のコマンドの定義、が行われた。
    • 実現のためにgitのcore.hooksPath を使っている
    • これでgit-hooksのshell scriptを保存する場所を.husky配下に変更する
    • hookさせるコマンドは .husky配下のschell scriptに記述する
  • husky v6
    • ほぼほぼhusky v5 の MIT版
  • simple-git-hooks
    • husky v5 の対抗馬として挙がったライブラリ
    • mrm (lint-stagedやprettierで推奨している初期設定便利CLI) のテンプレートが huskyからsimple-git-hooksに変更されていたが、現在はhuksy v6になっている。
    • こっちは core.hooksPath を使わず、package.jsonに定義したhook用のコマンドを .git/hooks 配下にコピーするもの
  • lefthook / pre-commit
    • より広い環境で使えそう

これからも自分のプロジェクトで husky を使う?

  • 自分が携わっているプロジェクトでこれからどうするか話す
  • @tatsuya
    • 一般ユーザーとしても、もちろんスポンサー企業所属のエンジニアとしてもhuskyを使っていく。
      • husky v4 は huskyが課題を持っている以上、使わない
      • 実装面ではhusky v6, simple-git-hooks は どちらも native の git-hooksの薄いラッパーとして差がほとんどない印象を持つ
      • OSSの認知度、コミュニティの規模の差で、husky v6
  • @amon
    • huskyを使っていきたい
      • 半分言い出しっぺだから、というのもあるが…w
      • gitネイティブ感があって好印象を持った
      • もともとポイントクラブでやってたことと相性が良かった
        • 新規メンバーが参加するときのセットアップもnpm installだけで済むし
  • @potato4d
    • husky はデファクトスタンダードであるから、積極的に使いたい
    • フロントエンドのツールチェインにはデファクトであったが今では課題がある技術もある
      • 例えば moment のような
      • 例えば lodash のような
    • husky は DX の向上が目的かつシンプルな git hook の支援ツールでしかないので、積極的に使って良さそう
      • ロックインや固有の課題がないなら、デファクトを支援するのはプロジェクト関係者にとって良いこと

Refs