43

npmを使用してフロントエンドの依存関係（Backbone、jQuery）を処理することが可能かどうか（そして一般的には良い考えです）を尋ねたいと思います。

Backbone、jQueryなどはすべてnpmから利用できることがわかりましたが、別の抽出ポイント（デフォルトはnode_modules）またはシンボリックリンクなどを設定する必要があります...

誰かが以前にこれをしたことがありますか？

出来ますか？

何を変更する必要がありpackage.jsonますか？

4

5 に答える 5

18

Browserifyを使用する場合は+1。ここdiy.orgで使用しており、気に入っています。Browserifyの背後にある最良の紹介と理由は、Browserifyハンドブックにあります。CommonJSおよびAMDソリューション、ビルドパイプライン、テストなどのトピックがここで取り上げられています。

Browserifyが非常にうまく機能する主な理由は、NPMを使用して透過的に機能することです。モジュールが必要である限り、ブラウザ化することができます（ただし、すべてのモジュールがブラウザで動作するように作成されているわけではありません）。

基本：

npm install jquery-browserify

main.js

var $ = require('jquery-browserify');
$("img[attr$='png']").hide();

次に、以下を実行します。

browserify main.js > bundle.js

次に、bundle.jsHTMLドキュメントに含めると、のコードmain.jsが実行されます。

于 2014-07-02T18:48:21.823 に答える
16

簡単な答え：ある種。

これをサポートするのは主にモジュールの作成者次第ですが、一般的ではありません。Socket.ioは、ランディングページに示されているように、そのようなサポートモジュールの例です。ただし、他の解決策もあります。これらは私が実際に知っている2つです：

  • http://ender.no.de/-Ender JS、クライアントモジュール用の自己記述型NPMアナログ。私の好みには少し複雑すぎます。
  • https://github.com/substack/node-browserify-Browserify。依存関係を調べ、node.jsモジュールパターンをエミュレートすることで単一のスクリプトを出力できるようにするユーティリティです。jake |cake | rake | makeビルドスクリプトを使用して、application.jsを吐き出すことができます。さらに、凝ったものにしたい場合は、自動化することもできます。私はこれを簡単に使用しましたが、少し不格好であると判断し、デバッグするのが面倒になりました。また、すべてのデュアル環境npmモジュールがbrowserifyを介して実行されることを好むわけではありません。

個人的には、現在、MozillaがBrowserQuestサンプルアプリケーション（ https://github.com/mozilla/BrowserQuest ）で行うのと同様に、RequireJS（http://requirejs.org/ ）を使用してモジュールを手動で管理することを選択しています。これには、AMDスタイルのモジュールローダーのサポートが削除されたバックボーンやアンダースコアなどのモジュールをシムする必要があるという課題が伴うことに注意してください。シミングに関係するものの例はここにあります：http：//tbranyen.com/post/amdrequirejs-shim-plugin-for-loading-incompatible-javascript

本当に、それは何があっても傷つくだろうように思われます、それがネイティブモジュールサポートがとてもホットな話題である理由です。

于 2012-07-07T05:24:17.533 に答える
5

私たちのチームは、フロントエンドプロジェクトを構築するためのLinemanと呼ばれるツールを維持しています。このツールはノードベースであるため、プロジェクトはサーバー側で動作する多くのnpmモジュールに依存してアセットを構築しますが、すぐに使用できる状態で、コピーおよびコミットされたクライアント側の依存関係を見つけることが期待されますvendor/js。

しかし、多くの人々（私自身を含む）がbrowserifyとの統合を試みており、（a）サードパーティによって保守されているnpmモジュールに至るまで、多くの複雑さと問題に遭遇しました。 （b） AMD / Require.jsの手荷物が原因で、名前付きのトップレベル関数が定義されている場合でも、従来の方法でロードすると失敗し始める実際のライブラリへの不要な変更。require

私の短期的な推奨事項は、ほこりが落ち着くまで、古き良きスクリプトの連結を保留して固執することです。問題が発生するまで、それを正当化するのに十分な大きさまたは複雑な問題が発生するまでは、ビルドのデバッグと修正に、そうでない場合よりも多くの時間を費やすことになると思います。そして、私たちのほとんどは、あなたの時間を最大限に活用するのは、ビルドツールではなく、アプリケーションコードに集中することに同意していると思います。

于 2014-07-02T19:06:36.843 に答える
3

ブラウザのパッケージマネージャであるhttp://jspm.io/を確認することをお勧めします。ES6もサポートしています。

于 2014-07-02T22:35:19.727 に答える
1

私は個人的に小さなプロジェクトにwebmakeを使用しています。これは、npmの依存関係をブラウザーにもたらす方法で、browserifyの代替手段であり、明らかに軽量です。

browserifyとwebmakeを詳細に比較する機会はありませんでしたが、socket.io（とにかく肥大化したIMOでいっぱいです）などのグローバル変数を使用するモジュールでは、webmakeが内部的にうまく機能しないことに気付きました。

上記で推奨されているRequireJSについては注意が必要です。これはAMDローダーであるため、ブラウザはJSファイルを非同期でロードします。それはあなたのクライアントとサーバーの間のより多くの交換を誘発し、モバイルネットワークから/悪いWiFiの下で閲覧している人々のUXを低下させるかもしれません。さらに、JSコードをシンプルで小さく保つことに成功した場合、非同期ロードは絶対に必要ありません！

于 2014-07-02T22:04:48.503 に答える