I'm trying to embed an EmberJS application into a large portal application which uses extensively the RequireJS library. I'm using ember-cli to build the project. The built application consists of two files, dist/assets/vendor.js
and dist/assets/myapp.js
. The EmberJS application works after embedding it but the portal app's javascript breaks.
After some research I've found out the problem is that vendor.js
defines its own variables require
, requirejs
, requireModule
and define
which conflict with the website's variables in the global namespace. The myapp.js
file then contains define
statements which load the app's modules.
Is there a way to rename these or to put them into some different namespace?
The only solution I came up with was to manually rename the variables within the two .js
files. This seems to work but it's rather cumbersome and it'd be nice if it could be automated. I have also found out about using RequireJS optimizer but I can't get it to work with the vendor.js
file.
Can you help me?
Thanks!
I was having the same problem, and after much searching I believe I managed to solve it by adding the ember-derequire addon to my project:
ember install ember-derequire
That will change all of the 'require' and 'define' statements in your app to 'eriuqer' and 'enifed'. You can override what it maps to using options (caveat being you have to use something the same length) if you don't like eriuqer and enifed.
In case that doesn't help, the other promising thing I found is that loader.js has a noConflict() function, but I couldn't figure out where to put the loader.noConflict() call, or get the build to generate code using alternate names, but maybe it will help you if the first option doesn't work for your situation.
As @Bjornicus (https://stackoverflow.com/a/39088322/5056421) wrote, built-in loader.js
's noConflict()
function seems to work correctly. I placed it in main JS file (app.js):
window.loader.noConflict({
define: "emberDefine"
});
and define
wasn't overridden (I import ember app to another app which uses SystemJS). But I've made only few tests, so I don't know if this does not break something later.