Added capability to wrap d3 as an AMD module.

[gregsymons]

To generate a wrapped d3, do:

$ make MODULE_TYPE=amd

The wrapped d3 will be found in d3-amd.v2.js and d3-amd.v2.min.js.

[gregsymons]

Should this go into the 2.9.8 branch instead?

[ferz]

Thank you for this improvement. I hope to find it in main d3.js distro soon.

[rfink]

Any update on this?

[jeffrose]

Would it make more sense to just use the amdWeb pattern from umdjs? That way AMD is used if it's present and browser globals are used if it's not.

[sheppard]

+1 on having d3 utilize the amdWeb pattern in the default build.

I'd go further and suggest that d3 itself might benefit from a transition to AMD modules internally (with r.js or similar to build the output file).

[Trakkasure]

Check the component user @ github: https://github.com/component
There is a D3 component created that utilizes the AMD style loading you are asking.

Plus, after loading all your components, creating a single minified file becomes simple to do.

Brandon Myers

On Monday, January 28, 2013 at 12:45 PM, S. Andrew Sheppard wrote:

+1 on having d3 utilize the amdWeb pattern in the default build.
I'd go further and suggest that d3 itself might benefit from a transition to AMD modules internally (with r.js (/jrburke/r.js) or similar to build the output file).

—
Reply to this email directly or view it on GitHub (#745 (comment)).

[sheppard]

Thanks for the link, though it appears that the referenced components (including the D3 component) are based on CommonJS rather than AMD. As I understand it, a key benefit of AMD over CommonJS is the ability to use & debug individual module files directly within the browser before building the singled minified file for deployment.

[Trakkasure]

I believe that this system supports just that. The minified version is the additional benefit (with all dependencies) that this system provides.

Brandon Myers

On Monday, January 28, 2013 at 2:20 PM, S. Andrew Sheppard wrote:

Thanks for the link, though it appears that the referenced components (including the D3 component) are based on CommonJS rather than AMD. As I understand it, a key benefit of AMD over CommonJS is the ability to use & debug individual module files directly within the browser before building the singled minified file for deployment.

—
Reply to this email directly or view it on GitHub (#745 (comment)).

[sheppard]

To clarify - given its dependency on the CommonJS module syntax, it seems unlikely that Component can automatically load source modules directly into the browser as-is, a key feature of AMD. AMD was created specifically to address the lack of asynchronous module loading in CommonJS, and thus requires a different module definition syntax (see http://requirejs.org/docs/whyamd.html for more information).

More to the point, since the AMD module format is not directly compatible with CommonJS, Component is not a useful option for those of us who are already using AMD. FWIW, a number of libraries (jQuery Mobile and Dojo being two prominent examples) have already or are in the process of migrating to AMD.

In order to use d3 in their projects, AMD developers have three main options:

• Use the "shim" capability in RequireJS (http://requirejs.org/docs/api.html#config-shim) - a stopgap measure at best.
• Maintain a custom version of d3 with AMD support added (a couple of lines of code, but still less than ideal)
• Work with the d3 community to add AMD support to the library. This pull request is just to add it to the final built file, which will be a great start. I also think there would be a benefit to converting all of the d3 source modules to the AMD format - but let's defer that discussion to a later time.

The amdWeb pattern provides a nice compromise between AMD and the traditional "browser global" approach. The nice thing is that it should not break any existing functionality. @gregsymons and others, would you be interested in updating this pull request (or creating a new one) with an amdWeb-based solution?

[sheppard]

This is fixed in 3.4

[mbostock]

Yep, fixed.