aiannacc / Goko-Salvager

Enhance your Dominion Online experience!
13 stars 9 forks source link

JSLint whitespace, grunt tasks to test and automatically regenerate extensions #227

Closed michaeljb closed 10 years ago

michaeljb commented 10 years ago

Most important change is probably grunt watch:chrome to automatically reassemble the chrome extension when changes are made.

As usual, npm install will need to be run for the new grunt tasks to work.

michaeljb commented 10 years ago

To see the diff ignoring whitespace change (i.e., the only change for a line is spaces/tabs were added/removed), add "?w=0" to the end of the URL, like so.

aiannacc commented 10 years ago

grunt watch:chrome, grunt watch:firefox, and grunt watch:safari watch for changes to relevant files and automatically run the rake tasks to assemble/build the extension for the given browser grunt watch:browsers automatically rebuilds all the browsers when a relevant file changes

Will this attempt a build every time I save an individual file? And will it attempt to build for Firefox and Safari for developers who don't have the necessary scripts available? If so, is there an easy way to turn it off?

michaeljb commented 10 years ago

You have to actually run the grunt command in a terminal window for it to run. When you do this, the grunt process will be waiting with output like this:

michael@Michaels-MacBook-Pro ~/projects/salvager $ grunt watch:chrome
Running "watch:chrome" (watch) task
Waiting...

If you want to do anything else in a terminal, you have to open up another one.

This will attempt to run "rake chrome:assemble" every time one of the files in watch.chrome.files is modified (it should be configured to all files that get packaged for chrome, plus the scripts that could change how it is built).

To avoid the automatic builds, you just have to not run any grunt watch command, and the standard control-C will kill a grunt watch process.

tl;dr no unwanted builds are thrust upon the developer :smile:

michaeljb commented 10 years ago

And apparently I managed to not respond to this part:

And will it attempt to build for Firefox and Safari for developers who don't have the necessary scripts available?

Yes, if grunt watch:firefox or grunt watch:safari is running (or grunt watch:browsers to rebuild all the things). If they don't have the necessary scripts, they should just get the exact same error as if they try to run the rake commands.

aiannacc commented 10 years ago

grunt qunit (and grunt test) work. Note that grunt-shell and grunt-contrib-qunit are required to use these.

grunt watch:chrome doesn't quite work. The "name" field in manifest.json ends up blank. I haven't checked whether watch:safari or watch:firefox have similar issues.

michaeljb commented 10 years ago

Hmm, I just got the same name issue with chrome running "rake chrome:assemble" directly (which is good, if I got a result different than the one from the watch task I would be really confused). Are you having this issue?

My rake is version 10.2.2, just tried with ruby 1.9.3, 2.0, and 2.1 and they all got the same result. Not sure what's going on but I'll keep looking.

michaeljb commented 10 years ago

I just checked out a revision from before I added any grunt stuff, 93e9a66, and got the same missing name issue.

michaeljb commented 10 years ago

I think I found the problem, calling the 'chrome:assemble' rake task without a 'title' argument, this is handled fine in the 'chrome:build' task. I was just using 'assemble' since you only really need the 'unpacked' version while developing.

Thanks for finding the issue, I'll get this fixed.

michaeljb commented 10 years ago

I actually won't be able to work on this until early/middle of next week. I'll re-open it when I have progress on it.

michaeljb commented 10 years ago

Now it's just passing the name directly from the grunt task.

To get a .zip or .crx, you'll still need to run "rake chrome:zip" or "rake chrome:build". I haven't been able to get the ssh stuff working with the build task correctly yet; it still interrupts the watch every time it needs the ssh passphrase.

aiannacc commented 10 years ago

So, for the ssh issue, you'd probably need to put your ssh public key in my server's authorized keys file.

First generate a key without a password ssh-keygen. Then send it to my server using either ssh-copy-id, if you have openssh or something equally awesome, or using scp (on .ssh/id_rsa.pub) if you don't. If you have to scp it over, you'll need to then ssh over and manually append your public key file to .ssh/authorized_keys.

But actually that doesn't really make sense to me, actually, since you're just doing a build, not a deploy. For that matter, did I ever even set up an account for you on my server? I don't see one there.

michaeljb commented 10 years ago

I don't think I've ever asked for you to set up an account for me on your server. I agree that that should not be the issue since I'm just trying to run the build task. I think it just asks for my passphrase to the key so it can sign the .crx; from some stuff I've read, I should be able to use ssh-add to sign it without asking for my passphrase every time, but I haven't figured out why that doesn't work yet.

On Mon, May 19, 2014 at 4:39 AM, Andrew Iannaccone <notifications@github.com

wrote:

So, for the ssh issue, you'd probably need to put your ssh public key in my server's authorized keys file.

First generate a key without a password ssh-keygen. Then send it to my server using either ssh-copy-id, if you have openssh or something equally awesome, or using scp if you don't. If you have to scp it over, you'll need to manually append it to .ssh/authorized_keys.

But actually that doesn't really make sense to me, actually, since you're just doing a build, not a deploy. For that matter, did I ever even set up an account for you on my server? I don't see one there.

— Reply to this email directly or view it on GitHubhttps://github.com/aiannacc/Goko-Salvager/pull/227#issuecomment-43487422 .

Michael Brandt

aiannacc commented 10 years ago

Ah. Okay, that makes way more sense. The only thing I can think of is that maybe ssh-agent isn't running.

I should do this merge now anyway, right?

michaeljb commented 10 years ago

Yeah, it's definitely still useful to automatically re-assemble the chrome files even without generating a .zip or .crx.

aiannacc commented 10 years ago

Looks good. I tested grunt qunit, grunt build:chrome, and grunt build:firefox. The extension names look correct now.

Actually, I rather like how grunt:chrome renames the extension "(developer version)". grunt:firefox doesn't do that, but it's certainly not critical.