Use a Universal Module Definition pattern to support globals
Closed this issue · 5 comments
I've read the discussion on Google Groups around the decision to drop the browser globals. I understand the sentiment, but you're leaving a lot of users out in the cold, here. It's one thing to advocate a module-based system but I think it's an entirely different thing to force your users to use such an environment.
The UMD project has plenty of recognized patterns that make it possible to support various environments. The pattern I would love to see adopted by cujojs (or at least meld), is the returnExports pattern. It supports Node, AMD (requireJS), as well as normal browser globals.
This way users can choose the mechanism that fits their environment (and are actually able to use meld.js in the browser, without moving their entire system to RequireJS).
Hey @jasonkarns. I'm open to legacy global usage via a build step, but not integrated into the code. If you have ideas on how that can be done, let's definitely discuss.
This is the modification I made locally so that I can use meld in my environment. https://github.com/jasonkarns/meld/compare/umd
It's nearly identical to the way 'define' is currently branching, with the added fallback of defining a global if not in a CommonJS or AMD environment.
@jasonkarns if it's ok for you to use Grunt as a build system for meld, I can provide build script that will produce different results depend on environment needed.
I'm gonna give the browserify grunt task a shot. It supposedly can convert between almost any module pattern (including globals).
Cool, let us know how it goes. browserify should work, and I bet component would as well. Both of them seem to be able to handle a single standalone amd/umd module fairly well.