6

一見単純なノードパッケージをnpmでインストールしようとすると（たとえば、神経、「マイクロフレームワーク」）、何らかの形の依存関係の問題に遭遇することがよくあります。少し掘り下げた後、私は神経の問題をbcryptモジュールに突き止めました。これは明らかにC / C ++で書かれており、パッケージマネージャーがダウンロードした後にコンパイルする必要があります。

残念ながら、これをWindowsで機能させたい場合、答えは（bcryptの問題のスレッドの1つから）「LinuxVMをインストールする」です。それで、今日私はちょうどそれをし、他の依存関係に遭遇し始めました（GCCがインストールされているにもかかわらず、ビルドについて考える前に、特定の名前のないaptパッケージをインストールする必要があります）、そして最終的にはさらに別のCコンパイラエラー（いくつかのパッケージまたは他に「Arrays.c」が見つからなかったと思います）、私は実際に諦め、代わりに神経質から表現に切り替えました。皮肉なことに、LinuxとWindowsにnpmを使用すると、問題が1つも発生せずに、より大きく複雑なExpressがインストールされます。

だから、私の質問は：パッケージにノードコア以外の追加の依存関係があるかどうかを確認できるフィルター/依存関係の追跡はありますか？私にとってノードの魅力は「Javascriptのすべて」であり、この種のものは非常に不快な幻想を払拭します。実際、C / C ++での作業以上のことを行ったにもかかわらず、最近何かを「作成」する必要がある場合は、通常、反対方向に叫んで走ります。:)

4

3 に答える 3

15

最初の解決策では、依存関係によってパッケージが不純になるかどうかはわかりません。gypで生成された出力を検索する方がはるかに優れています。

find node_modules/ | grep binding.gyp || echo pure
于 2016-07-01T13:14:14.960 に答える
3

ノードコアを拡張する1つの方法は、c / c ++プラグインを作成することであるため、ノードは「すべてのJavaScript」ではありません。

つまり、NodeはV8を使用するc /c++モジュールのJavaScriptラッパーです。

たとえば、純粋なJavaScriptで効率的なデータベースドライバを作成するにはどうすればよいでしょうか。それは可能ですが遅いでしょう。

フィルタに関しては、彼のパッケージを文書化するのは作者次第です。自動フィルターはありません。

于 2012-05-10T16:57:24.017 に答える
3

package.jsonの「scripts」フィールドに注意してください。

次のようなものが含まれている場合

 "scripts": {
    "install": "make build",
 }

ルートディレクトリにMakefileがある場合、パッケージにネイティブモジュールが含まれている可能性が高く、コンパイルしてビルドする必要があります。多くのパッケージには、テストをコンパイルするためだけにMakefileが含まれています。

パッケージドキュメントに対するこのチェックは、依存関係をコンパイルして構築する必要がある可能性を排除するものではありません。これは、package.jsonの依存関係、それらの依存関係などごとにこのプロセスを繰り返すことを意味します。

とは言うものの、多くのモジュールは、Windowsでビルドせずに、1つのエクスプレスをインストールするように更新されています。ただし、すべてのパッケージについて保証することはできません。

LinuxVMを使用するのが最善の方法のようです。WindowでNode.jsアプリケーションを開発すると、VM、Node.js、およびExpressをインストールする手順がわかります。

于 2012-05-11T03:11:07.243 に答える