browserify-handbook からの抜粋翻訳です。 ライセンスはCC BY 3.0 です。 書いたのは、かつてNode.js界で人気のライブラリをたくさん作っていた substack 。
DHHのおまかせ思想 と対比するとおもしろいです。
変更点:
- 原文でrequire()となっていた部分を「requireあるいはimport」としました。
良いモジュールの探しかた
ブラウザで動く良いnpmモジュールを探すにあたっての役に経つ経験則をいくつか書いておく:
- npmでインストールできる
- READMEのコードスニペットで
require()あるいはimportを使っている ― パッと見で、現在書いているコードにどうやって組み込むのかがわかるべきだ - スコープと目的にたいして、とても明快で限定されたアイデアを持っている
- いつ、他のライブラリに委譲すべきかわかっている ― それ自身であまりにもたくさんのことをこなそうとしない
- ソフトウェアのスコープ、モジュラリティー、インターフェイスについて、自分が同意できるような意見を持った作者によって書かれている、あるいはメンテされている(しばしば、コード/ドキュメントを詳細に読むよりも手っ取り早いショートカットになる)
- どのモジュールが、評価中のライブラリに依存しているのか調べる ― これは、npmに公開されたモジュールのためのパッケージページに焼き込まれている
githubのスター数や、プロジェクトアクティビティー、見掛け倒しのランディングページのような他の指標は、これらほどには信頼できない
モジュール哲学
人々は、かつて、お手軽なユーティリティースタイルのあれこれをまとめてエクスポートするのが、プログラマがコードを利用する主な方法になると考えた、なぜなら、それがnpm以外のほとんどのプラットフォームにおいてコードをエクスポートやインポートする主要な方法だからだ。実のところ、npmにおいてさえもいまだにそのようなやりかたは続いている。
しかしながら、この 典型的なメンタリティー (テーマ的に関連しているが分離可能な機能をひとつのパッケージに含める方を向いている)は、前github、前npm時代における公開と探索の困難を解決するための遺物であるように思われる。
利便性の庇護の元に機能を一箇所にまとめてエクスポートしようとするモジュールには、二つ大きな問題がある: 境界線を決めるための縄張り争いと、どのモジュールが何をしているのかの探索だ。
機能がごちゃ混ぜになったパッケージは、どの新機能が入り、どれがそうでないのかの 境界を管理するのに多大な時間を浪費させる 。この種のパッケージの問題領域において、スコープが何なのかについて明快で自然な境界はない、すべては どこかのだれかの独り善がりな見解だ 。
Node, npm, そしてbrowserifyは、そうではない。これらは、公式にアラカルト、参加型であり、見解の相違や、雨後の竹の子のように新しいアイデア・アプローチが出てくることをむしろ祝福し、こういったものを一致、標準、あるいは「ベストプラクティス」の名の元に押さえ込むことを良しとしない。
ガウシアンぼかしが必要な人で、「うーむ、どのモジュールがガウシアンぼかしを含んでいるか知るためには、まず、一般的な数学、統計学、画像処理、それから便利ライブラリのチェックからはじめる必要があるだろうな。stat2か、image-pack-utilsか、maths-extra、あるいはunderscoreに入っているということもありえるか?」などと考える人はいない。ない。こんなやりかたありえない。やめるんだ。ガウシアンぼかしが必要な人は、npmをgaussinで検索し、直ちに ndarray-gaussian-filter が目に入り、それはまさしくかれらの欲しいものである。そして、だれかの巨大で便利だが放置された領地を前に呆然とするかわりに、かれらの実際の問題に戻る。