用browserify导出内部库依赖关系到外部作用域

我使用browserify来要求bluebird在跨我的WebApi Wrapper for Dynamics CRM中承诺的跨浏览器兼容使用。它迄今为止效果很好，但是我不喜欢这样做，例如在IE返回的调用结果中我不能执行Promise.all，而不在我的首页中再次包含蓝鸟。因此，我希望我的browserify包将Promise公开给全局范围。当然，它只会做global.Promise = require("bluebird")，但那种感觉很脏。使用独立软件包我做到了，我的独立软件也将我的客户端暴露为属性和Promise。然而，名称变长这种方式，我希望能够在任何地方都能使用Promise（没有我的独立包装）。用browserify导出内部库依赖关系到外部作用域

您对此有何看法？这是可能的还是我不应该那样做？

我现在做的是定义我的客户为IIFE，和里面做到以下几点： module.exports = { Client: WebApiClient, Promise: Promise };

和browserifying像browserify src/js/WebApiClient.js -d --standalone XrmWebApi -o Publish/WebApiClient.js。这样我目前能够使用XrmWebApi.Client和XrmWebApi.Promise，但我非常想摆脱XrmWebApi来调用promise。

感谢您的帮助。

亲切的问候，弗洛里安

来源

2016-10-22 DigitalFlow

创建全局定义一个新的文件，然后添加在你的包步骤的切入点。

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

你可能会想删除对bluebird引用您的文件src/js/WebApiClient.js和它的依赖，只是使用Promise。

来源

2016-10-23 08:08:02 casr

您是否知道将我的客户定义保留为IIFE是否是一种更好的做法，还是将它作为module.exports公开会更好？ – DigitalFlow

我不确定你想达到什么，所以我会猜测。浏览器不会理解你的'module.exports'。我看了一下你项目中的最后一个提交，我猜你对你添加的'globals.js'方面的IIFE很感兴趣。这似乎没有必要。您应该可以从“browserify src/js/globals.js”中看到browserify提供的输出。它会显示在你的终端上，你会看到代码已经包装在你的IIFE中。 – casr

我会评论需要蓝鸟的线路，因为它只会使输出不可读。你会看到'browserify'周围的代码被缩小了。 https://github.com/substack/browser-pack/blob/01d3989/prelude.js，如果你想学习它更轻松一点，一个无懈可击的版本已经结束... – casr

用browserify导出内部库依赖关系到外部作用域

回答

相关问题