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
Always expose D3 onto the environment global #1921
With regards to #1689 adding AMD compatibility, it seemed odd to me that
Within a discussion about this very problem, found here:
the argument is made that exposing the global defeats the point of
This patch will fix third-party modules that are shimmed.
Man, AMD support really opened up a can of worms, and I wonder if I regret it.
My take away is that jQuery is “special”, but I don’t know whether D3 is special in the same way that jQuery is special.
Like jQuery, D3 is also a “foundation of other third party libraries that all assume a global is available”. So should D3 provide a global? The problem with D3 not providing a global is that every D3 plugin (also see d3/d3-geo-projection#9) must support AMD, or the plugin breaks because of a ReferenceError on the
Like jQuery, D3 is “commonly used as a dependency by other libraries” and D3 “is also the defacto implementation of the module interface implied by that name”. So should D3 register as a named module, too? I have no idea. The discussion suggests that in the future jQuery will switch to an anonymous module.
So I guess our options are:
Options 1 & 2 aren’t exclusive, and would be most in continuing with our existing approach.
Option 4 is arguably the best for users, regardless of whether they are using AMD, though it’s a weak compromise that doesn’t establish a clear policy for other libraries. (Should queue and topojson export a global too?) Also, it’s still possible for advanced users to create their own custom build if they don’t want the global, or if they want to load D3 as a named module.
So I guess I’ve convinced myself to agree with you and export a global. And I’ll probably change my other libraries to do the same. For one thing, this will make me happy on nytimes.com because d3 will finally work in the console again…
Hey @mbostock thanks for taking the time for a well thought out response. I'm glad you merged this PR as it will fix a lot of headaches and confusion I've shared. I have some comments below to address your options:
The new ES6 modules specification has almost no momentum, but hopefully it will address the pain in even thinking about this stuff. I can sympathize too; I've implemented UMD incorrectly several times trying to be clever and hating the whole decoration necessity.
Aww, I was hoping for Option 2 to become adopted as a "standard" approach so I could stop having to add AMD wrappers to plugins myself. Oh well, a global d3 isn't the end of the world. FWIW, even under AMD you could always do a synchronous
in the console as long as d3 has already been loaded once asynchronously.