【LibraUI開発日誌 #5】LibraUIをnpxコマンドでソースごと組み込ませる意義
どうもこんにちは、Libra UI絶賛開発中の起平です。
なるべく週に1回、土日にはnoteの記事をアップしたいと思っているものの、開発に集中していたり、平日の夜は睡魔に襲われChromebookを開くことなく眠ってしまう日が続いてしまいました。
さて、今回の記事は、コンポーネントやライブラリをnpmに公開しない方にはあまり関係がない内容かもしれません。しかし、私が「なぜ、あえてnpxでソースを組み込ませるのか？」というテーマにたどり着いた経緯と、その裏で直面した苦労について、お話ししたいと思います。
npm install と npx の違い、わかりますか？
フロントエンド開発に携わる方であれば、npm installやnpxといったコマンドはよく使うことでしょう。（ちなみに、私はC#erなのでフロントエンド開発の時しか使いません。）
Material UIなど、多くのライブラリはnpm install ライブラリ名で自分のプロジェクトに組み込むのが一般的です。正直なところ、私も「npm installとnpxって何が違うの？」と、ずっとぼんやり思っていました。
そんな中、今年の初め頃だったでしょうか。ReactのUIコンポーネントを探していた時に、shadcnという存在を知りました。この出会いは、私にとって衝撃的でした。
なぜなら、それまでのUIコンポーネントは、提供された仕様の元で開発し、内部の構造を変更することはできない、いわばブラックボックスの状態だったからです。
しかし、shadcnは違いました。
『ライブラリのコードを自分のプロジェクトの一部にすることができる』
これは、フロントエンド開発のあり方を変革する可能性を秘めていると感じました。AIのような劇的な変化とは違い、「自社（または私）が作りたいUIコンポーネントってこれじゃないんだよな…」という不満を解消してくれる。「骨格（＝ヘッドレス）ができたものを導入して、見た目や動きをカスタマイズできる」という新たな開発体験に変わるのです。
苦悩の始まりとnpm公開の裏側
私は、この先このような開発体験が主流になると感じました。そして、現状SolidJSには、こうしたヘッドレスなUIコンポーネントが充実していない。
それならば作るしかない。そう思って開発したのがLibra UIです。
前回の記事で、ついにnpmに公開したことをお伝えしました。しかし、その後に自分自身で確認してみたら、まったくと言っていいほどうまくいかなかったのです。
ここから先が、今回の本題です。npmに公開したはいいものの、npxコマンドで自分の開発者用ソースにコンポーネントをインポートしようとした際に直面した具体的な問題、そして、その解決策についてお話しします。
第一の試練：謎のエラーメッセージとの格闘
自分のプロジェクトでnpxコマンドを実行したとき、最初に目の前に現れたのは、このような見慣れないエラーメッセージでした。
import: not found
Permission denied
Syntax error: "(" unexpectedimport: not found？()が予期しない？最初はJavaScriptの構文エラーかと思いましたが、どう見ても正しいはず。何時間もコードを見直したり、ビルド設定をいじってみたりしましたが、原因がまったく分かりませんでした。
結論から言うと、これはコードの問題ではなく、実行環境の問題でした。
私が公開したJavaScriptファイル（.mjs）が、Node.jsではなく、OSのデフォルトシェル（shやbashなど）によって実行されようとしていたのです。つまり、シェルはimport構文や関数の()を理解できず、文法エラーとして扱っていたわけです。
原因が分かれば、解決策は明確です。シェルではなくNode.jsで実行されるように、.mjsファイルの先頭に次の文字列を入れることで解決しました。
#!/usr/bin/env nodeこれはさすがにAIに聞かないと自分では解決できない問題ですね・・・。
第二の試練：型チェックの壁
無事にインポートできるようになったかと思いきや、今度は開発環境の型チェックでエラーが発生しました。
「あれ？コンポーネント側でビルドしたときはこんなエラー出ていなかったのに…」
原因は根深いところにあり、コンポーネントを開発した際のTypeScriptの設定と、それを使う側のプロジェクトの設定に微妙な違いがありました。
具体的には、私のプロジェクトとユーザーのプロジェクトで、TypeScriptの「strictモード」の設定が異なっていました。コンポーネント側の環境では厳格な型チェックをしない設定だったためエラーが出ていなかったのですが、npxで試したプロジェクトではstrict: trueが有効になっており、より厳格なチェックが走っていました。
この問題を解決するため、コンポーネント側の設定をstrict: trueに統一し、厳格な型チェックを導入しました。
苦労の先に見えた景色
この一連のトラブルを通じて、私はnpxでライブラリを公開することの責任を痛感しました。それは、「利用する開発者に、より安全で信頼性の高いライブラリを提供しなければならない」です。
何気なく使っているnpxコマンドや、公開されているOSS（オープンソースソフトウェア）の裏には、こうした膨大な試行錯誤があるのだと気づきました。
私が悩んだような問題は、おそらく海外のOSS開発者も経験しているはずです。それでも、ユーザーが快適に使えるように、見えないところで様々な工夫や努力をしてくれている。そのことに、改めて感謝の気持ちが湧いてきました。
今回の経験を糧に、私は「ユーザーに最高の開発体験を届ける」という目標を掲げ、Libra UIの開発を続けていきます。
今のLibra UI（https://github.com/OkihiraHijirikawa/solid-libra-ui）のバージョンはv0.2.2になりました。
npxでソースを組み込ませてみた結果、色々と見直さなければならなかったのと、ディレクトリをもう一度見直したのでそういった意味でマイナーアップしています。
まずはv1.0.0になるまで頑張らねばなりませんね！