Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
wrapShim config #623
A built file with shim config can fail if it has an intermediate dependency that is an AMD module but downstream dependencies are not AMD.
Canonical example: Backbone depends on jQuery and Underscore. jQuery and Underscore do not have any dependencies, so they can also export a global value when they run, and only call define() at the end with the global they set up.
However, Backbone needs jQuery and Underscore loaded before its main module body can execute. So it is not executed right away, it is executed once the dependencies have had their define()'d factories called.
But if there is a shim config for something that depends on Backbone, that shimmed dependency wants Backbone available immediately when it executes, and it does not have a define() wrapper.
Before a build, this all works because the shimmed dep is not fetched until Backbone is fully defined. However, in a build, with all the dependencies inlined, there will be a failure.
A way to avoid this is to wrap the shimmed dependency in a define() call -- this avoids executing it until its dependencies are available.
I have traditionally avoided this because by wrapping, it changes the scope for the shimmed dependency. If that dependency is doing a
So allow shimmed scripts to be wrapped, and try to mitigate the wrapping effects. For the
This fix is in master now, it can be tried by using this version of r.js, until 2.1.11 is released:
@KidkArolis I am still concerned about the scope changes wrapping introduced, and given that existing behavior did not wrap, I do not want to automatically change people's projects to introduce wrapping.
I could see though that after we have had this capability in use for a while, and we see it does not have any issues, then for a 3.0 type of release, it could be switched to true by default.
added a commit
Mar 13, 2014
referenced this issue
Mar 13, 2014
I'm finding these two rules conflict:
Shim config is always a less desirable option, since the goal of having a module loader is to use modules with well defined, internally specified modules. There is always a limit to the extent of being able to support shims, since they are just inferior to actual modules, this is one of them.