AMD support

[crossbario]

AMD support

[oberstet]

What "AMD" are you referring? RequireJS? What changes would be needed for "CommonJS support"? In any case, I agree with the general issue that AutobahnJS should be a "better citizen" in the JS world. I.e. node and NPM support would also be useful. PR: sure, we are accepting pulls ..

[beatgammit]

Yes, RequireJS.

For CommonJS, I meant support for ender, pakmanager or cpm. Ender is pretty popular and uses NPM as it's backend, and a coworker of mine developed pakmanager, which was supposed to do more than Ender.

Anyway, I personally don't care too much about CommonJS, but I do use RequireJS, and I would be happy to submit a PR. There are a couple of ways I can do this:

• Wrap the existing code in autobahn/autobahn.js
• Plug into a build tool and generate wrapped copies
• Copy the file and make an AMD-specific version

Which do you prefer?

[oberstet]

In general, it must not introduce new dependencies or introduce additional build tools (regarding the build system, I'd be open to migrate to node though in principle). What kind of changes would be required for RequireJS within AutobahnJS?

[beatgammit]

Here's a recently closed PR on one of my repositories: beatgammit/crc32@3a20f14

Basically, it's just a small wrapper that:

• if define is defined, does AMD loading
• if require is defined, does CommonJS loading
• otherwise, attaches it to the global namespace, just like AutobahnJS currently does

That's what the newer cross-tool libraries do. It's not too much overhead, and it stays out of the way relatively well. It's probably the best option since it covers all three, but I wasn't sure what the policy was.

[oberstet]

Looks good. So above approach is downwards compatible (works for people not using any package/module management)? And this approach would be the "Wrap the existing code in autobahn/autobahn.js" option of your other comment? Then please go ahead with that option ..

[oberstet]

I have been reading a little about package managers and such. Have been looking at http://browserify.org/ .. which looks fine to me. There is also Ender http://ender.jit.su/

And here is a comparison of Jam, Require, Ender and Browserify http://www.reddit.com/r/javascript/comments/vc9d9/npm_vs_jam_requirejs_vs_browserify_vs_ender/

Currently I am leaning towards

"AutobahnJS works both in browser and in server (e.g. node) environments"

as a desirable feature of AutobahnJS.

If so then I guess Browserify or Ender which reuse the package repository (the http://npm.org site), management (the npm tool) and module system (CommonJS), while extending on dependency management would make up a good fit for AutobahnJS.
Together with a build tool like UglifyJS, we'd have a complete node/npm based toolchain.

[beatgammit]

Jam, however, doesn't use the npm repository. It's basically the package manager for requirejs, so it's pretty popular with that crowd. That would mean, however, that two repositories would have to be maintained: one for ender/node and one for requirejs. These two can use the same exact code, so nothing complicated there.

To support node, you'll need a WebSocket library (something like ws) since, AFAIK, there's no default WebSocket object in node.

I'll probably get a PR ready sometime soon for RequireJS compatibility, but I'd like to know who should publish to Jam.

[oberstet]

Yes, for AutobahnJS on Node, we need to use a WebSocket library (ws is one, another one would be https://github.com/Worlize/WebSocket-Node. FWIW both are tested using AutobahnTestsuite).

I agree, it looks like we need to be both in NPM and Jam if we want to take a neutral stance on this stuff. Which I would prefer. A little library such as Autobahn should not impose any "conditions" such as package management & modue system on a user.

(Btw: why did Jam create a new repository instead of using NPM?)

Regarding who should publish: at this point, I'd argue this should be done by me. I create an account and will read up a little.

So in the AutobahnJS code, we would a) add something like the "3-variant wrapper" you got as PR in your repo and b) add some module metadata files so we can publish to both NPM and Jam?

[beatgammit]

I've heard a couple reasons:

• if the npm repository goes down, Jam won't be affected
• less confusion about which is a Jam module and which is a node module

I'll try to get that wrapper done soon. It won't take long, but I've just been a little busy lately. I will be needing to use it in the near future, so it'll probably happen this week.

[oberstet]

Added empty module https://github.com/tavendo/AutobahnJS/tree/master/module and NPM project https://npmjs.org/package/autobahn

[oberstet]

Sketch for supporting all 3 (stolen from http://tjholowaychuk.com/post/27984551477/components):

   // AMD support
   if (typeof define === 'function' && define.amd) {
       define(function () { return Cookies; });
   // CommonJS and Node.js module support.
   } else if (typeof exports !== 'undefined') {
       // Support Node.js specific `module.exports` (which can be a function)
       if (typeof module != 'undefined' && module.exports) {
           exports = module.exports = Cookies;
       }
       // But always support CommonJS module 1.1.1 spec (`exports` cannot be a function)
       exports.Cookies = Cookies;
   } else {
       window.Cookies = Cookies;
   }

...
// Expose for component
module.exports = jQuery;

// Expose jQuery to the global object
//window.jQuery = window.$ = jQuery;

// Expose jQuery as an AMD module, but only for AMD loaders that
// understand the issues with loading multiple versions of jQuery
// in a page that all might call define(). The loader will indicate
// they have special allowances for multiple jQuery versions by
// specifying define.amd.jQuery = true. Register as a named module,
// since jQuery can be concatenated with other files that may use define,
// but not use a proper concatenation script that understands anonymous
// AMD modules. A named AMD is safest and most robust way to register.
// Lowercase jquery is used because AMD module names are derived from
// file names, and jQuery is normally delivered in a lowercase file name.
// Do this after creating the global so that if an AMD module wants to call
// noConflict to hide this version of jQuery, it will work.
if ( typeof define === "function" && define.amd && define.amd.jQuery ) {
define( "jquery", [], function () { return jQuery; } );
}

})( window );

[oberstet]

Also see here: https://github.com/umdjs/umd

[philippemiguet]

Is there any advancements on this issue? Or has someone a temporary hack to make it work with amd?

[jameslai]

+1

[oberstet]

provided in v0.8.0