package axs_testing.js independently about accessibility-developer-tools

[ckundo]

I propose we create a grunt "release" task that will create a versioned branch with static version of axs_testing.js in a tracked folder. For now, devs can point to the raw file on from the release branch on github to include the tests. Further out, maybe we can get the rules hosted on a CDN.

[alice]

SGTM

[ckundo]

@alice the following npm package for closure compiler supports compiling both debug and production versions more easily than the one we're using, and seems like it has more activity. I think we should consider using it for this approach. It has an MIT license, if that makes any difference. https://npmjs.org/package/grunt-closure-compiler

[ckundo]

I've created a release branch where we can rebuild and tag release versions. Github tracks the releases based on the tag:

https://github.com/GoogleChrome/accessibility-developer-tools/releases

I'll work on a grunt task to make this automated. @alice, any word on the MIT licensed package from the previous comment?

[alice]

Apologies; checking with the Open Source team now.

On Thu, Sep 12, 2013 at 6:30 AM, Cameron Cundiff
[email protected]:

I've created a release branch where we can rebuild and tag release
versions. Github tracks the releases based on the tag:

https://github.com/GoogleChrome/accessibility-developer-tools/releases

I'll work on a grunt task to make this automated. @alicehttps://github.com/alice,
any word on the MIT licensed package from the previous comment?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/39#issuecomment-24318825
.

[alice]

Yep, all good!

On Thu, Sep 12, 2013 at 8:04 AM, Alice Boxhall [email protected] wrote:

Apologies; checking with the Open Source team now.

On Thu, Sep 12, 2013 at 6:30 AM, Cameron Cundiff <[email protected]

wrote:

I've created a release branch where we can rebuild and tag release
versions. Github tracks the releases based on the tag:

https://github.com/GoogleChrome/accessibility-developer-tools/releases

I'll work on a grunt task to make this automated. @alicehttps://github.com/alice,
any word on the MIT licensed package from the previous comment?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/39#issuecomment-24318825
.

[alice]

One thing: this grunt task doesn't seem to include the closure compiler, so
we'd have to go back to including the closure jar in the repository as far
as I can tell.

On Thu, Sep 12, 2013 at 10:03 AM, Alice Boxhall [email protected] wrote:

Yep, all good!

On Thu, Sep 12, 2013 at 8:04 AM, Alice Boxhall [email protected]:

Apologies; checking with the Open Source team now.

On Thu, Sep 12, 2013 at 6:30 AM, Cameron Cundiff <
[email protected]> wrote:

I've created a release branch where we can rebuild and tag release
versions. Github tracks the releases based on the tag:

https://github.com/GoogleChrome/accessibility-developer-tools/releases

I'll work on a grunt task to make this automated. @alicehttps://github.com/alice,
any word on the MIT licensed package from the previous comment?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/39#issuecomment-24318825
.

[ckundo]

@alice, are we using closure-compiler for anything other that requiring, concatenating, and minifying? Node had built in filesystem tools for requiring, and there are other tools that we can use to concat and minify.

[ckundo]

Sorry, I wrote that last comment too early in the morning. I realize we're using closure compiler extensively for building objects. Disregard!

[alice]

Yeah - it's primarily used in a linting capacity, with a side effect of
moderate minification/concatenation. I started using it because I was going
crazy trying to debug javascript errors caused by typos etc, plus it forces
you to rigorously document the inputs/outputs of functions and checks that
you're using it correctly.

A couple of times I've looked into using other JS build tools but I haven't
yet found one that does as good a job at picking up that type of error (for
example, I ran closure over the Polymer codebase, which uses uglifyjs, and
immediately found a bug that their tooling hadn't picked up).

One thing in the back of my mind is considering switching to full
minification using the closure compiler - i.e. switching to
ADVANCED_OPTIMIZATIONS - but this would require rethinking much of the code
structure and being more rigorous about what is considered part of the
public API. I think that would be a good exercise to go through at some
point, though.

On Sun, Sep 15, 2013 at 11:04 AM, Cameron Cundiff
[email protected]:

Sorry, I wrote that last comment too early in the morning. I realize we're
using closure compiler extensively for building objects. Disregard!

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/39#issuecomment-24476500
.

[ckundo]

I discovered a configuration option in the existing closurecompiler library that creates a debug version of the file. I do think that if we wanted to use another linting library, we can capture any method input/output issues by unit testing more thoroughly, but right now what we have will do fine.

[ckundo]

I agree about refining the public API and more aggressively minifying. I've been poking around https://github.com/jquery/jquery and https://github.com/twbs/bootstrap to get cues on best practices and strategies for this kind of library.

We should consider it further for a future release.