Add bower support

[loginx]

I'm working on integrating ADT into a suite of jasmine tests loaded through karma and karma-requirejs.

Unfortunately, npm modules aren't accessible by these tests because they aren't available to the client side app. We would have to rely either on a submodule inside of our build, or manually copying axs_testing.js into our test build each time.

It would be useful to have a bower config for the project, and publish it on release.

I'm willing to work on building the config and any release automation tooling that would be needed, provided that's something you guys want.

[ckundo]

@loginx have you considered using Broswerify to include the module contents clientside?

[loginx]

I haven't, but I'm not sure that would help. Isn't the axs_testing build something that can already run in a browser environment? I assumed so since that's basically what the runner script does in the phantomJS process.

All bower would do, is just make it easier for client builds to include that file.

[ckundo]

@loginx yes, we load axs_testing into the browser with Phantomjs. I was thinking you could use the library directly by including the module with Browserify, but I think you may be right, I'm not sure that will work since axs_testing is compiled and does not support requirejs. @addyosmani would your a11y node module work with Browserify to include the library clientside, since you're using requirejs? Are there other approaches besides Bower?

[loginx]

Loading the precompiled axs_testing already works from requireJS. It's not ideal since it works by setting globals instead of using AMD convention, but there's probably a clean way of dealing with this.

From what I can tell, a11y does the same as your runner in that it basically does webpage.injectJs('PATH_TO_AXS_TESTING'). It's not including the library through requireJS.

[ckundo]

@loginx thanks for the clarity. @alice, if you're open to supporting Bower, I can help review @loginx's PR.

[alice]

Supporting bower would be fantastic!

[loginx]

Ok thanks @alice. I'll start working on that right now. I'll probably end up breaking up the work into the following tasks, and submitting individual PRs for each task:

• bower config
  • Once that's merged and tested, we can do the module registration using the bower CLI tool.
• release management task for grunt (optional)
  • Bower requires semver compliant tags to be added into the repo for each release.
  • I can pretty easily set grunt up to automatically perform the following tasks for you:
    • Update the version in package.json based on a CLI task param
    • Commit and push the new package.json
    • Create and push a git tag with the same name as the new release version
• Generate an AMD compliant module
  • I'll look into whether it might be possible to set things up so that the current module can automatically register into an AMD if gets loaded by one.
  • If not, simplest way is to generate a second module axs_testing_amd that wraps the first.

We can skip the release management if you want, but you'll have to remember to create and push a new git tag for each release, or bower won't be aware of it.

[alice]

I've been meaning to figure out a release management grunt task anyway, so if you want to get the ball rolling on that it would be greatly appreciated!