underscore.js，名为“exports"的全局对象；和 livefyre javascript API - 集成冲突

问题描述

我会尝试总结几个步骤并在之后提出问题

I'll try to summarize a few steps and ask a question after

1. underscore.js 在开发第 3 方 javascript 组件时安装失败(如下所述:Underscore.js 和 noconflict).我的代码包含以下行以避免 underscore.js 的不同版本发生冲突:

1. underscore.js failed to install when developing a 3rd-party javascript component (as described here: Underscore.js and noconflict). my code included the following line to avoid collisions of different versions of underscore.js:

window.$MyUS = _.noConflict();

window.$MyUS = _.noConflict();

查看 underscore.js 代码时，发现如果定义了 exports 或 module.exports，那么_ 变量将成为 exports 或 module.exports 的成员.它只是发生了(当然在浏览器中，而不是在 Node.js 中).

when looking into the underscore.js code, it was found that if exports or module.exports is defined, than the _ variable will become a member of exports or module.exports. It just happened (in browser, not in Node.js of course).

我尝试在加载 underscore.js 之前将 exports 对象保存在一边并删除它，并在调用 noConflict() 后立即恢复它.但是，当调用delete exports时，我得到了false，这意味着不能删除exports.

I've tried to save the exports object aside and delete it before loading underscore.js and restore it right after calling noConflict(). However, when calling delete exports, I've got false, which means that exports can't be deleted.

我在 exports 对象中发现了两个成员函数:compile() 和 compileToString().通过查看他们的实现，我发现了 LF 引用，这些引用可能指的是 livefyre Javascript API (http://www.livefyre.com/docs/javascript-sdk-reference)

I've found two member functions in exports object: compile() and compileToString(). By looking into their implementation I've found LF references which perhaps refer to livefyre Javascript API (http://www.livefyre.com/docs/javascript-sdk-reference)

解决冲突的更好方法是什么?我看到以下选项:

Which is the better way to resolve the conflict? I see the following options:

1. 修改 underscore.js 代码，使其不会尝试将自身安装到 exports 对象中.

1. Modify the underscore.js code so that it won't try to install itself into exports object.

让 underscore.js 修改 exports 对象，希望任何网站都不会出错.在这种情况下，我需要像这样重写 window.$MyUS = _.noConflict(); 行:

Let underscore.js to modify the exports object and hope that nothing wrong will happen on any site. In that case I will need to re-write the window.$MyUS = _.noConflict(); line like this:

window.$MyUS = .noConflict ||.noConflict() ||...;//为清晰起见省略了健全性检查，显然生产代码必须更健壮

window.$MyUS = .noConflict || exports..noConflict() || ... ; // sanity checks omitted for clarity, obviously the production code must be more robust

如果您需要更多信息 - 请询问.

If you need any more info - please ask.

推荐答案

我认为答案很简单:fork 在 GitHub 上划下划线 并添加一个简单的补丁，如果 window 存在，则拒绝将自身附加到 exports，并提交拉取请求.

The answer, I think, is simple: fork underscore on GitHub and add a simple patch that refuses to attach itself to exports if window exists, and submit a pull request.

这样每个人都会受益:每次升级下划线副本时都不必重新应用补丁，其他人也不必处理该问题.

That way everyone benefits: you don't have re-apply your patch every time you upgrade your copy of underscore and others don't have to deal with that problem, either.

这篇关于underscore.js，名为“exports"的全局对象；和 livefyre javascript API - 集成冲突的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！