add support for AMD and CommonJS

[stebunovd]

no jQuery dependency for AMD or CommonJS, but jQuery will be used if available in global scope. All tests passing. Solves #150

[timlindvall]

I believe we could get around swapping out window.hopscotch with a couple of changes...

• Use (function(){...}).call(winHopscotch);
• Update the namespace for the jst task in Gruntfile.js to use templates instead of hopscotch.templates.

[timlindvall]

Hi @stebunovd, thanks for the pull request! Would love to see Hopscotch work well in whichever context its used within. A contemplation about how to best handle Hopscotch in multiple environments...

Originally, I believe this was something we were planning to address as part of refactoring Hopscotch in 0.3.0. When originally thinking through the problem, the solution I was leaning towards was to use common environment-agnostic JS code that was then included (using the include-replace grunt task) in wrappers for their particular environment. This would result in multiple files (Hopscotch for AMD, CommonJS, window global) and the developer would import the file that works best for their environment (instead of having Hopscotch interpret what to use depending on window globals). Hopefully this allows the developer to best reason about how Hopscotch is invoked in their app and cuts down on code that's isn't required for every environment.

Do we believe this sort of build target separation be useful, or would this just convolute things?

[stebunovd]

Hi @zimmi88,

thank you for pointing out how to avoid that hack for templates.

the pattern I used here for AMD/CommonJS support is called UMD, see https://github.com/umdjs/umd. This is a well-tested and widely used solution, which can be found in many JS libraries. Size overhead doesn't seem to be large, and having one universal file looks simpler and clearer from my perspective. In most cases users want all libraries in their environment to support the same format, either AMD, or CommonJS, or browser globals, so auto-detect works fine. Even if I want to do something different, say export library object from CommonJS environment to browser global scope, this is pretty easy to do either by single line of code window.hopscotch = require('hopscotch'), or using built-in tool of my favorite JS bundler. For example, see exports loader for Webpack http://webpack.github.io/docs/list-of-loaders.html

[kate2753]

We should remove jQuery and YAHOO from factory params, since they are optional library dependencies. Somebody quickly looking at the source code might assume they are hard dependencies. You should still be able to do hasJquery = (typeof jQuery !== undefinedStr), inside factory method, since it will assume window scope anyway.

[kate2753]

Thank you for the pull request! Overall these changes look good to me. My only concern is jQuery and YAHOO params to factory function. It would be nice to remove them.

[stebunovd]

A matter of habit. I write all my JS code with 'use strict';, so I always try to avoid implicit calls to global scope. However hopscotch.js doesn't use strict mode, so you're right, these params are redundant.

[kate2753]

Looks good to me! I'll pull it in tomorrow if there are no other comments.