-
-
Save jchillerup/1603424 to your computer and use it in GitHub Desktop.
var socket = io.connect('http://HOSTNAME:8080'); | |
socket.on('reload', function (data) { | |
location.reload(); | |
}); | |
/* | |
socket.on('eval', function(data) { | |
eval(data.evalString); | |
}); | |
*/ |
var io = require('socket.io').listen(8080); | |
var http = require('http'); | |
io.sockets.on('connection', function (socket) { | |
// nothing currently | |
}); | |
http.createServer(function (req, res) { | |
res.writeHead(200, {'Content-Type': 'text/plain'}); | |
res.end('Reloading clients\n'); | |
io.sockets.emit('reload', {}); | |
}).listen(1337, "HOSTNAME"); | |
console.log('Server running at http://HOSTNAME:1337/'); |
Oh! Now I totally get it. Then it'd make sense to make a hook in wr
that could call a function when it's done building. This function could then do whatever is needed to reload the browsers. If you take the code as-is from this gist, you can cause all clients to reload by running curl http://HOSTNAME:1337/
or wget
if you prefer.
However, I do agree that it would be nice with something a little more polished. Also something that required the reloader app to auth to the server that the clients are listening to somehow. A challenge/response system with a shared secret would probably do for that. Sounds like a Sunday morning project :-)
For unit testing you could look at BusterJS(.org). I haven't tried it, though, so I don't know much about it.
Also, I simplified the gist code somewhat. Apparently socket.io already had built-in broadcast capability. As an added bonus, we won't have lingering records of old sockets in the allsockets
array that used to be there.
I don't see it as a hook to wr, at least yet, but a standalone command I would add to my Makefile
. If I ever server-ize wr, then I think maybe it would make sense to add it there, somehow.
w/r/t auth. Nope. I'd say, for the first pass, no auth, but you only run the server so it accepts connections from localhost. Safe enough. The biggest security hole would be shipping your code with the reloader
script still in it. People have shipped pages in production that included the weinre target bits, which is the same, horrendous, security exposure. Or an awesome hack, whatever your tastes.
In fact, I don't even need to "switch to browser", I just need to be able to see it, in most cases.
Now, if only I can automate the "edit code" and "press the save key" steps, I can retire.
Another way to do this would be to run a test server, have the build open a browser window on the tests served by the test server, have it run the tests, and send the results back to test server, which would be reported as success/failure of the build, along with any relevant messages. Then close the window.
For some reason, I think someone's done something like that before.