今日、クライアント側のJavascriptライブラリをモジュール化してパッケージ化する方法は？

私は最新のクライアントサイドJSエコシステムに追いつき、CommonJSとAMD（関連ツール-browserify、requirejs、onejs、jam、その他多数）について調べています。Javascriptライブラリを作成する場合、最も広くアクセスできるようにモジュール化/パッケージ化するにはどうすればよいですか（理想的には、CommonJS、AMD、および特にどちらにも誓わないユーザーが）。

jQueryのような人気のあるライブラリは、それ自体を構築するために旧式のファイル連結を使用しexports、グローバルコンテキストに書き込むべきかグローバルコンテキストに書き込むべきかを動的に検出するようです。私は現在同じことをしていますが、主な欠点は（jQueryとは異なり）いくつかのライブラリに依存している場合、推移的なセットを手動で事前に含めるようにユーザーに要求する必要がないことです。（ただし、現在は2つの依存関係しかありません。）そしてもちろん、グローバルな名前空間の汚染。

それとも、コンテキストごとにライブラリの複数のバージョンを生成するのが最もクリーンですか？

パッケージングとパブリッシングについても考えています。いくつかのシステムがありますが、主なものはバウアーであり、フェッチするだけなので対処が簡単です。ただし、コンポーネント（CommonJSが必要）のような他のパッケージシステムもターゲットにすべきかどうか疑問に思っています。

他に知っておくべき関連する側面はありますか？これらすべてについて従うべき良いサンプルプロジェクトはありますか？

私は以前からビルドファイルを使用していましたが、最初のnodejsプロジェクトを開始してからbrowserifyを使用し始め ました。browerifyおよび他の同様のライブラリを使用すると、コードがビルドファイルになります。私は両方で実行できるクライアントおよびサーバーライブラリを利用していますが、純粋にクライアントコードでも動作します。それをまとめると、browserifyはノードでコードを書くことのすべての利点を提供し（グローバル、npm、単純な要件を回避するための匿名関数はありません）、1つのコマンドでクライアントで実行するコードをパッケージ化し、1つのファイルのみをロードできます。

browserifyを使用すると、次のようなことができます（名前はapp.js）：

var MyLib = require('../myLib');

if(typeof window !== 'undefined') {
    window.MyLib = MyLib;
    window._ = require('underscore');
    window.$ = require('$');
    window.MyLib.myCan = require('./3rdParty/can/can');
}

browserify app.js> client.js

次のようなものを生成します：

[function(require,module,exports){
    window.MyLib = //MyLib code
},
function(require,module,exports){
     window._ = //_ code
},
function(require,module,exports){
    window.$ = //$ code
},
function(require,module,exports){
    window.MyLib.myCan = //can code
}

定義するファイルには、すべてのサードパーティライブラリが含まれている可能性があり、それを使用する開発者と衝突することはありません。

-コメントに応じて編集（および質問の完全なミス）

これは依存関係と、すべてのバージョンとライブラリで機能することを確認するためにどれだけの時間を費やすかによって決まると思います。依存関係が一般的で、バージョン間で同じAPIを使用している場合、バックボーンルートに移動して、ユーザーに$と_を要求するだけで済みます。あいまいなライブラリをバンドルファイルの一部として置くことをお勧めします。オプションもカットして乾燥させる必要はありません。事前に構築されたパッケージを提供することも、独自のパッケージを構築することもできます。

クライアント側ライブラリの種類：

1. DOMに触れる
2. DOMに触れない

最初の種類（UIウィジェットなど）では、通常、jQueryが存在すると想定します。また、「DOMライブラリに依存しない」と記述し、あまり人気のないライブラリでも機能させることができますが、気にしません。

第二種と。まず、jQueryプラグインにしないでください。たとえば、「jQuery cookieプラグイン」はばかげていますが、そのようなライブラリは実際に存在します。

これらの種類はどちらも、依存関係、小さな依存関係、または巨大な依存関係を持たない可能性があります。この意味で、domライブラリは依存関係としてカウントされません。最初の2つでは、ライブラリスコープ内でそれらを連結するだけで、重複の可能性について心配する必要はありません。たとえばisArrayLike、ユーザーがいくつかのランダムユーティリティベルトライブラリから自分自身を既に含めている場合でも、jQueryは内部関数を連結します。

ライブラリ（実際には言語）を開発するときに、大きな依存関係を持つ個人的な経験は1つしかありませんmoment.js。この場合、2つのビルドを提供します。1つは連結されたmoment.jsを使用し、もう1つは使用せずに、ユーザーがそれを含める責任を負います。しかし、これが良い解決策かどうかはわかりません。

そして、はい、すべての場合において、うまく機能する最終的な大きなファイルを1つ作成するjQueryアプローチが採用されています。モジュールのボイラープレートが下部にあります（必須/ AMD /グローバルなどの検出）。