サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
iPhone 17
shinnn.github.io
これまで100個以上のnpmモジュールを作成してきましたが、そのほとんどを素のJavaScriptを使って書いています。つまりCoffeeScriptなどのJSに変換されるメタ言語や、ES.nextなシンタックスを現在利用可能なコードに変換するbabelなどのツールを使用していません。 (これはモジュール作成の際の話です。Webアプリケーション開発においては、寧ろ積極的に活用しています。) そういったトランスパイラを使って書いていた時期もありましたが、現在ではほぼ全て素のJavaScriptで書き直していますし、今後新たにモジュールを作る際も使わないつもりです。 これは「リポジトリ全体の可読性」を考えてのことです。ファイル単位で見れば、エレガントなシンタックスで可読性が向上するかもしれません。しかし、トランスパイラを使うとなれば、JSへの変換手順の用意(npm scriptやgulp.js
Node、ひいてはJavaScriptを取り巻く環境は目紛しく変化し、ライブラリやフレームワークもそれに合わせて日々更新され続けています。特にNodeモジュールの場合は、それ自体のコードはもちろん、頻繁に行われる依存パッケージのアップデートも精査の対象としなければなりません。そんな環境の中で、大量のコードまたは複雑なパッケージ依存関係を持つにも関わらず、何ヶ月、あるいは何年も更新されていないNodeモジュールを使うのは、少なからぬリスクがあると考えるべきでしょう。 放置されたモジュールをそのまま使わずに、フォークして自身の用途に合わせて修正を行うというのも(オープンソースらしい)一つの手段です。同様の目的を果たすモジュールをコードベースから書き直して作成する手もあります。あるいは、既に別の開発者が代替手段となるモジュールを作ってくれている場合もあるでしょう。 そういった、代替物を探す/作る
Nodeではchild_process.spawn()などで特定のコマンドを別プロセスで実行することができますが、前提としてそのコマンドが実行可能な状態でなければなりません。当該コマンドにPATHが通っているかどうかはnode-whichなどで確認できますし、ドキュメントに「事前に◯◯というプログラムをインストールしてください」とリクワイアメントを書いておけば利用者は対応できます。 しかし、できることなら利用者にそのような手間をかけさせたくはありません。npm installコマンドひとつでNodeプログラムに必要なファイルは全て揃ってほしいものです。ではどうするのかというと、npmのパッケージと同じように必要ならバイナリーもダウンロードしてしまえば良いのです。このような、一見強引ながら極めて合理的な解決策を提供するのがbin-wrapperです。 bin-wrapperを使うbin-wr
このページを最初にブックマークしてみませんか?
『Shinnosuke Watanabe』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く