Open gordonbrander opened 12 years ago
It may be possible to automate wrapping for AMD using r.js. Even make
might do the trick. For most modules, this means wrapping with:
define(function(require, exports, module) {
//Put traditional CommonJS module content here
});
AMD is ok, but it would probably be better to use the bigger "universal module factory" boilerplate.
I've found that it's possible to automate conversion to AMD modules. This r.js
build profile generates a working AMD module after running the library files through r.js
's AMD wrapper script.
AMD support is ok. Would still prefer a global module format, as with your Streamer library.
Renamed bug to reflect what I believe we agreed upon:
we need a make file to build in a target based flavor:
make amd
make browser
Let me just say that the last thing I want to do is argue about JS module formats. I don't care -- I just want modules, and I want them to work.
With that out of the way, I think in the long run it will be helpful to have universal module wrappers for files in this library. The thing is, requiring CommonJS modules +
browserify
is a lot to ask from developers on the client side:browserify
generates -- like any generated source, it means you end up troubleshooting code that doesn't match the code you wrote.browserify
.Modules are an annoying problem in JavaScript, because right now there is no elegant solution. This means you should do whatever causes the least amount of annoyance for your library's users.
But for libraries that are supposed to be used everywhere, the best thing for your audience is to make it "just work". AMD, CommonJS, whatever. It should just work.
Making this happen is ugly boilerplate for library developers, but convenient for library consumers. Maybe it could just stay in a branch. Regardless, I think it makes sense.