現在、私defines
は Google Closure Compiler を介して と の行に沿っていくつかを使用してIS_CJS
おりIS_BROWSER
、ビルドされるさまざまなファイル ( 、 など) がありbrowser.myproject.js
ますcjs.myproject.js
。
これは物事を行う標準的な方法ですか?そうでない場合、それは何であり、どのような利点がありますか?
現在、私defines
は Google Closure Compiler を介して と の行に沿っていくつかを使用してIS_CJS
おりIS_BROWSER
、ビルドされるさまざまなファイル ( 、 など) がありbrowser.myproject.js
ますcjs.myproject.js
。
これは物事を行う標準的な方法ですか?そうでない場合、それは何であり、どのような利点がありますか?
私はすべてのプロジェクトで、ブラウザー コードとサーバー コードの両方によって読み込まれるライブラリに対して、次のプリアンブルを使用しています。
if (define === undefined) {
var define = function(f) {
require.paths.unshift('.');
f(require, exports, module);
};
}
define(function(require, exports, module) {
...
// main library here
...
// use require to import dependencies
var v = require(something);
...
// use exports to return library functions
exports.<stuff> = { some stuff };
...
});
これはrequire(<library>)
、ノードサーバーで実行されているrequire(<library>)
呼び出しと、RequireJSを使用した呼び出しでライブラリをロードするために機能します。ブラウザでは、ネストされたrequire
呼び出しは、ライブラリの実行前に RequireJS によってプリフェッチされます。ノードでは、これらの依存関係が同期的に読み込まれます。ライブラリを (html の script タグを介して) スタンドアロン スクリプトとして使用しておらず、script タグを介してロードされたスクリプトの依存関係としてのみ使用しているため、これはうまく機能します。
ただし、スタンドアロンのライブラリを見ると、次のプリアンブルが最も柔軟なようです。(Q promise ライブラリからカット アンド ペースト
(function (definition, undefined) {
// This file will function properly as a <script> tag, or a module
// using CommonJS and NodeJS or RequireJS module formats. In
// Common/Node/RequireJS, the module exports the Q API and when
// executed as a simple <script>, it creates a Q global instead.
// The use of "undefined" in the arguments is a
// micro-optmization for compression systems, permitting
// every occurrence of the "undefined" variable to be
// replaced with a single-character.
// RequireJS
if (typeof define === "function") {
define(function (require, exports, module) {
definition(require, exports, module);
});
// CommonJS
} else if (typeof exports === "object") {
definition(require, exports, module);
// <script>
} else {
Q = definition(undefined, {}, {});
}
})(function (serverSideRequire, exports, module, undefined) {
...
main library here
...
/*
* In module systems that support ``module.exports`` assignment or exports
* return, allow the ``ref`` function to be used as the ``Q`` constructor
* exported by the "q" module.
*/
for (var name in exports)
ref[name] = exports[name];
module.exports = ref;
return ref;
});
冗長ですが、非常に柔軟で、実行環境に関係なく簡単に動作します。
AMD または CommonJS で記述されたモジュールを、テンプレート システムを介して AMD、CommonJS、または UMD に変換するuRequireを使用できます。
オプションで、uRequire はバンドル全体を、内部で rjs オプティマイザーとアーモンドcombinedFile.js
を使用するすべての環境 (nodejs、AMD、またはモジュールのないブラウザー < script/>) で実行される としてビルドします。
uRequireを使用すると、各モジュールでボイラープレートを維持する必要がなくなります。単純な AMD または CommonJS モジュール (.js、.coffee、.coco、.ls など) をギミックなしで記述するだけです。
さらに、メソッドと一緒にモジュールをグローバルにエクスポートするなどの標準機能を宣言的に追加したり、 runtimeInfo (__isNode、__isAMD など) を選択的に使用したり、ビルド中に依存関係を置換/削除/注入したり、モジュールコードを自動的に縮小したり、操作したりできます。もっと。window.myModule
noConflict()
これらの構成オプションはすべて、バンドルごとまたはモジュールごとにオンとオフを切り替えることができ、互いに派生 (継承) するさまざまなビルド プロファイル (開発、テスト、運用など) を持つことができます。
grunt-urequireまたはスタンドアロンを介してgrunt でうまく機能し、変更されたファイルのみを再構築する優れた監視オプションがあります。
これを試しましたか: https://github.com/medikoo/modules-webmake#modules-webmake ?
これは私が取っているアプローチであり、非常にうまく機能しています。コードにボイラープレートがなく、サーバー側とクライアント側の両方で同じモジュールを実行できます