Wano株式会社

【解説付き】フロントエンドライブラリ私流選定基準

Last updated at 2023-12-21Posted at 2023-12-21

この記事は Wano Group Advent Calendar 2023 の22日目の記事となります。

アドカレ22日目！

こんにちは！TuneCore Japanでフロントエンド会社員をやっている @rom1000_onigiri です。
街もすっかりイルミネーション模様が馴染んで、クリスマスに向けて気分を盛り上げてくれてますね

さて、22日目のこの記事では フロントエンドライブラリの選定基準 について書きたいと思います。

本題の前に

ライブラリに着目するタイミングっていつでしょうか？

導入する時
剥がす時
更新する時

この3つのタイミングではないでしょうか。
今回はその 導入する時 にフォーカスを当てて、私が実際に用いた選定基準を紹介します。

ライブラリって日々の実装では全然目につかず、ひっそりと実装を楽にしてくれている縁の下の力持ち的存在ですよね。
しかしいざ着目する3つのタイミングで大きく壁を作ってきます。

「導入後長く付き合うものだから慎重に選定しないと…」
「剥がしたら動かなくならないかな…」
「更新後何が変わって何が廃止されて何が追加されたの…」

浮かぶ不安にキリがありません。
その不安を払拭するために、適切に情報を集めてそのライブラリをしっかり理解することが大切です。

この記事は、

ライブラリを導入したいけど、何を指針にしていいかわからない
ライブラリを提案するために、決め手をまとめて信頼性を強固にしたい

という方を対象にした内容になっています

筆者は大変心配性なもので、ここまで入念にやる必要ある？と思われるかもしれませんが悪しからず……
あくまでご参考程度に、「この観点忘れてた！追加しよ」「この観点はいらないかな」など取捨選択して、あなた流の選定基準を作り上げるお手伝いになれたらと思っています

私流選定基準

生意気にも「私流」とか言っていますが、0から観点を生み出すことは毛頭できないのでベースとして参考にした記事があります。

新しいJavaScriptライブラリを評価するために考慮すべき12のことがまとめられています。
2018年と古めの記事ですが時代を問わないベーシックな観点がまとめられていたので、基準作りにかなり役に立ちました。

上記記事も踏まえた上で実際に設定した私流ライブラリ選定基準は以下のとおりです

①要求が満たせるか

これは言わずもがなですが…
ライブラリを導入したいということは、それが必要であり満たしたい要求があるということです。
譲れない要求 と 譲歩できる要件 を明確にしておきましょう。
まず最初にふるいにかける基準がこれになります。

②できることの範囲は適切か

できることがたくさんあるライブラリは、一見便利に見えます。
しかし、将来その多機能便利ライブラリの使用をやめたい時や、別の素敵なライブラリに乗り換えたい時、その罠に気がつくことになります。
アプリケーションと密結合 になって剥がすことが容易でなくなってしまうのです。

フロントエンドの技術は流行り廃りのスピードが速いと言われています。（実際私もそうだなあと感じます）
フロントエンドのライブラリにもそれが当てはまります。
ライブラリが多機能であればあるほど、アプリケーションがそのライブラリに依存し切ってしまい、剥がしたり乗り換えするコストが高くなるとともに、時代に沿った適切な技術の適用がしにくくなってしまいます。

それを避けるためにも、要求は満たしている && 代替が効くくらいのレベルで選定しましょう。

③破壊的変更の頻度

エンジニア感覚的に、

バージョン	変更量
メジャーバージョン	仕様や機能が大きく変わる（破壊的変更が盛り込まれるのはこのレベルが多い）
マイナーバージョン	機能改善や小さな機能追加
パッチバージョン	バグ修正くらいの軽微な修正

こんな感じの規模をイメージします。
ですがバージョン番号の付け方は開発者の自由にできるので、必ずしも上記表に沿ったリリースになっていないケースももちろんあります。

githubのReleases（changelog）を確認してみましょう。

「ここ最近はパッチバージョンしかリリースされていないから安定しているな」

と油断していると危ないかもしれませんよ。
マイナーバージョンでもパッチバージョンでも、破壊的変更が含まれている可能性はゼロではありません。
Releases（changelog）の見出しやサマリーだけ確認するだけでなく、PRの中身やきっかけとなったissueも確認できるとベターですね。

Releasesを確認した上で、破壊的変更の頻度が多いとアップグレードのコストは高いので、導入はあまり好ましくありません。
これは運用コストを少なくするための基準です。

④メンテナンスされているか

確認したい点は以下2つです。
下記の頻度が低いと品質もそこで停滞してしまっていることになります。
これは安定した品質の維持を担保する基準です。

コミットの頻度

githubのコミット履歴を確認してみましょう。
リリースされてほぼそのまま…やコミット頻度が極端に少ないのは、品質を維持していないことに繋がります。
たとえ何の機能も追加しなくても、依存モジュールのアップグレードなどコミットする必要は出てくるものです。

issueの対応状況

issueが立って議論されることはとてもよいことです。ライブラリがブラッシュアップされている証拠ですね。
ですがissueが立ちっぱなしでコメントがつけられていなかったり、bugfixのPRが放置されていてissueがcloseされていないなど動きがなかったら不安になりますよね。

頻繁にissueでの議論が行われていたり、bugfixのPRを適切に対応しcloseさせ健全な循環が行われているのが好ましいです。

⑤人気か && 有名か

④と相互関係がある印象なのが、多くの人に使われているかという基準です。
以下の2つを確認しましょう。

npmのダウンロード数
- Weekly Downloadsでダウンロード数の遷移を見て、変にアンインストールされているような謎な動きがないか確認したりなど
githubのスター数
- github上では総数しか表示されないので、コンスタントに上昇しているのか一時的な流行りだったのか判断がつきにくい
  - 下記WEBツールを使うとスター数の遷移図が確認できるので参考になった

多くの人に使われていたりするライブラリは、継続的なメンテナンスが行われていたり、issueでの議論も活発なように見受けられます。
また、潜在的な不具合も使われていく中で洗い出されているのではと考えます。

⑥リファレンスは充実しているか

導入したライブラリを使うのは、そのアプリケーションに関わる全員です。
もしそのライブラリで問題があった時や、そのライブラリを使用してアプリケーションの機能拡張の実装をする時など、知識の拠り所になれるものが満足にないとチームの開発パフォーマンスが落ちてしまう可能性があります。

公式で用意されているリファレンスが充実しているか、
（インストール方法やAPIが詳しくまとめられているか、情報が古いままになっていないかなど）
WEBで検索して満足に技術記事（参考事例など）が出てくるかも大切な基準です。

⑦実装言語

そのライブラリのために、無駄になり得る依存先を増やさないか、手元の環境を汚さないかの基準です。
例えば、アプリケーションはTypeScriptで実装されているのにPHP製のライブラリを入れては、そのライブラリのためにPHPをインストールすることになってしまいます。
そうでなくアプリケーションの実装言語と同じTypeScript製のライブラリを選ぶのが好ましいですよね。

いざ導入！する前に知っておきたいこと

ここまで入念に調査をしても、いざ導入に着手した際につまずくことはよくあります。
そんなケースを回避または適切に対応できるように、知っておきたいことがいくつかあります

見えないところに答えがあることもある

一見ドキュメントがしっかりしているライブラリのように見えても、公式リファレンスやexamplesに載っていないプロパティなどがあるケースがあります。

実際、「こういうことできないのかな、リファレンスにそんなプロパティ載っていないから無理か〜」と思いつつダメ元でぼんやりgithub見に行ったら、「初見のプロパティいる…しかも要求満たせる…」みたいな経験がかなりありました。
まるで宝探しのようですね！
issueがきっかけで便利プロパティが追加になっていたり、代替プロパティや代替コンポーネントが作られていたりするケースも見受けられました。