Lacking support for CommonJS

Question

Lacking support for CommonJS

rileyjshaw opened this issue 9 years ago · comments

Operative plays nice with AMD but resorts to a global in CommonJS loaders. Here's an example of a Universal Module Definition that covers all bases.

James Padolsey commented 9 years ago

Thanks!!

Riley Shaw commented 9 years ago

(see #38)

James Padolsey · Answer 1 · Tue Apr 14 2015 23:47:34 GMT+0800 (China Standard Time)

Hmm yeh should probably get this in. Thanks for opening an issue! Up for putting together a PR?

Riley Shaw · Answer 2 · Mon Apr 20 2015 18:16:47 GMT+0800 (China Standard Time)

@padolsey done! Sorry for the delay :)

Riley Shaw · Answer 3 · Mon Apr 20 2015 23:35:05 GMT+0800 (China Standard Time)

No worries :)

Sent from my iPhone

On Apr 20, 2015, at 3:46, James Padolsey notifications@github.com wrote:

Thanks!!

—
Reply to this email directly or view it on GitHub.

Riley Shaw · Answer 4 · Mon Apr 27 2015 16:02:02 GMT+0800 (China Standard Time)

Hey @padolsey - bad news :(

Because some of the submodules (eg. OperativeContext.js) are relying on the global operative, this still doesn't work well in a bundle. I see two routes from here:

Remove checks for both AMD and CommonJS, create a global operative by default, and leave the Grunt concatenation untouched.
Rewrite the modules to use AMD or CommonJS, and bundle them with something like grunt-browserify.

Option 1 has the advantage of minimizing change to the library, and removes the need for more complex bundlers (it's just concatenated .js files). Option 2 has the advantage of allowing the library to be consumed transparently by any client, and removing an unnecessary global in bundled settings.

Sorry to bring this back up - I thought #34 was sufficient, but I hadn't considered the other files that are concatenated with operative.js...

Riley Shaw · Answer 5 · Mon Apr 27 2015 16:02:26 GMT+0800 (China Standard Time)

I can make a PR for either option, just wanted to get your thoughts before moving ahead.

James Padolsey · Answer 6 · Mon Apr 27 2015 16:20:51 GMT+0800 (China Standard Time)

Ah, yep, I should have noticed that. Definitely up for option 2 if you have the time. The concatenation is a bit of a mess now.

Riley Shaw · Answer 7 · Mon Apr 27 2015 16:21:33 GMT+0800 (China Standard Time)

Though option 2 has obvious benefits, lines like this might make it pretty hard to remodel. For the time being I think that unbreaking things quickly with a global is the right course of action.

Let me know what you think! Sorry this wasn't as easy as I'd initially thought.

James Padolsey · Answer 8 · Mon Apr 27 2015 18:02:11 GMT+0800 (China Standard Time)

That __run__ would only be exposed in the generated iframe, but I still agree that this all might be more trouble than it's worth (at least at the moment). Shall look into your PR.

James Padolsey · Answer 9 · Mon May 04 2015 20:19:53 GMT+0800 (China Standard Time)

(Closing for now; I would very much like to revisit this at some point though)