リントやフォーマットをn⁠p⁠x⁠で

プロジェクトで使うリンターとフォーマッターをインストールせずに(させずに)npxで呼ぶパターンはどうなのかという実験をしている。遅いと言えばそれはもう間違いなく遅いが、いずれにしてもインストールより実行の時間が支配的なので、実用的な速度であるとは言えそうだ。たまに呼ぶ、またはGitのフックで呼ぶような場合には問題なく使えるだろう。

最初のnpm installが格段に速く終わる点をどう捉えるか、で評価が変わるだろう。最初に我慢すればその後は普通になるのが良いか、ずっと不快ではない状態が続くのが良いか。トレンドとしては前者のような気がするので、あまり受け入れられないかもしれない。npm installがよく失敗することなども考慮に入れると、「不快ではない」というのは開発のストレスを減らす良いアプローチだと考えられる。僕はnpx経由の方が悪くないという結論になりつつある。

npxを使うと、グローバルにインストールされているものが使われてしまう、という偶発的な問題を回避できる点も優れている。壊れているように見えないが実は壊れている環境(例えば依存が違うブランチを切り替えた後のnpm installをし忘れた環境)でも確実に動いてくれそうな点も良さそうだ。

問題はバージョン違いによる設定の不整合をどうするか、という点だけに感じた。依存管理をnpxでのバージョン指定に頼るしかなさそうなため、手作業での管理になる。そのためケアレスミスもそうだが、設定またはコマンドが古いまま更新されない問題も起こりやすく、ひいてはバージョンを上げる時の負担が積み重なっていってしまう。このあたりをちゃんとやる方法を考えないといけない。


Vimとかから呼ぶ場合はあまり実用的ではなかった。これが実用的ならばグローバルにインストールする必要がなくなって幸せになれそうだったが、さすがに保存時にザクザク実行される場合には無理があった。

非同期で呼べばなんとか……というところだが、特にフォーマッターでは感覚がつかみにくい。変更がある時はわかるが、変更がなかった時がわからないので、どれくらいで触ってよいのかよくわからなくなってしまう。ブロックしてしまった方が脳に優しい。


Windows上でnpxを実行するとPath must be a stringなどと出るのはnpm由来のバグのようだ。出力がおかしくなるだけで、特に実用上の問題はない。また既にそれを修正するだけのPRが作られており、直りそうなので気にすることはない。