2016-10-22 14 views
0

私はWebApi Wrapper for Dynamics CRMのブラウザ間での約束の使用にブルーバードを必要とするためにbrowserifyを使用しています。 これまでのところ素晴らしいですが、私は私のトップページにブルーバードを含めずにIEで返された呼び出し結果に例えばPromise.allを行うことができないのが好きではありません。 このような理由から、私はブラウザでバンドルして、プロミスをグローバルスコープに公開したいと思っています。もちろん、それはちょうどglobal.Promise = require("bluebird")を実行するために働くだろうが、それは一種の汚れを感じる。 スタンドアロンバンドルを使用して私のスタンドアロンは私のクライアントをプロパティとPromiseとして公開しています。しかし、名前はこのように長くなり、どこでも私のスタンドアロンラッパーを使わずにPromiseを使用できるようにしたいと考えています。内部ライブラリの依存関係をbrowserifyで外部スコープにエクスポート

あなたはどう思いますか?それは可能なのですか、それともしないのですか?私は今何

は、生命維持としての私のクライアントを定義しており、その中に次の操作を行います。 module.exports = { Client: WebApiClient, Promise: Promise };

browserify src/js/WebApiClient.js -d --standalone XrmWebApi -o Publish/WebApiClient.jsようbrowserifying。 私は現在、XrmWebApi.ClientとXrmWebApi.Promiseを使用することができますが、約束を呼び出すためにXrmWebApiを取り除きたいと思っています。

ありがとうございました。

種類よろしく、 フロリアン

答えて

0

あなたのグローバル定義のための新しいファイルを作成し、あなたのバンドルのステップでエントリポイントとしてそれを追加します。

src/js/globals.js

var bluebirdPromise = require("bluebird"); 
global.Promise = global.Promise || bluebirdPromise; 

browserify src/js/globals.js src/js/WebApiClient.js -d -o Publish/WebApiClient.js

あなたはおそらく、あなたのファイルsrc/js/WebApiClient.jsとその依存関係にbluebirdへの参照を削除し、ちょうどPromiseを使用したいと思うでしょう。

+0

私のクライアント定義をIIFEとして残しておく方が良いか、それともmodule.exportsとして公開する方が良いでしょうか? – DigitalFlow

+0

私はあなたが達成しようとしていることを確信しているので、推測します。ブラウザはあなたの 'module.exports'を理解しません。私はプロジェクトの最後のコミットを見ました。あなたが追加した 'globals.js'に関するIIFEに関する疑問があると思います。それは不要です。 browserifyが 'browserify src/js/globals.js'からあなたに与える出力を見るべきです。これは端末に表示され、コードがすでにIIFEでラップされていることがわかります。 – casr

+0

私はブルーバードが必要な行についてコメントします。なぜなら、出力を読むことができなくなるからです。あなたは 'browserify'周囲のコードが縮小されているのを見るでしょう。あなたがもう少し簡単にそれを勉強したい場合は、甘やかされていないバージョンはhttps://github.com/substack/browser-pack/blob/01d3989/prelude.jsで終わりです。 – casr

関連する問題