CommonJS modules

[inca]

Hi, guys,

I know that this is a kind of a long shot, but current module system can be described as just JavaScript chunks that are concatenated together to form a giant script that pollutes global namespace and is entirely unfriendly to other npm modules and browserify.

Furthermore, since Rangy is included, it does its own feature detection (sniffs module, exports and require) which prevents the entire library from being used with Browserify transforms (such as deglobalify).

Have you considered implementing CommonJS module system?

P.S. Production builds would be super-easy with Browserify.

[inca]

Looking forward for core team opinion on this one. If you don't mind the big changes, I can assist in rewriting modules into CommonJS format.

[pulges]

Current plan is to make it RequireJS/AMD compliant while keeping the option to run it as standalone without requireJS. Also the ability for users to extend the module with custom commands etc should be kept. No analysis about how much refactoring and api changes it will take, but the changes have to be done eventually anyway. It is currently not in our short-list, but all external help is welcome and handled ASAP.

[inca]

Thanks for your feedback! My opinion is pretty inline with this one. In my practice module loader sniffing is becoming pretty annoying now that people tend to assemble their JavaScript assets using server-side tooling like Browserify and Uglify. Modules which try to be "too smart" (UMD) always require special treatment (with derequire, deamdify, derequire, debowerify, decomponentify, etc.).

Now, I've already scouted through sources and sketched up a plan for migration. It would, unsurprisingly, affect every js file out there; however, some additional reorganization required to eliminate cyclic dependencies (since right now most modules are bundled onto the wysihtml5 namespace, while using constants defined on wysihtml5 object at the same time). Introducing separate constants module would resolve this issue, while leaving wysihtml5 as top-level exports object.

To sum things up: it is kinda doable, but would require some effort.

[pulges]

The new version 0.6.0-beta has removed the bundled rangy UMD wrappers now. Also does not add any other UMD wrappers itself, to comply better with server side bundlers and leaving open the door for ES6 module pattern if it starts working in browsers. Any other blocking problems when bundling or can the issue be closed?

[trickeyone]

I anyone else comes across this, I did go through and make it AMD/CommonJS compliant. It may be a little dated, though. I made it about 6 months ago. https://github.com/trickeyone/wysihtml