I chose to build the commands into the file with a comment rather than add an extra config file. For your test-compile cycle for Go, I think that would look like this at the top of each of your go files:
# autorun go install ./cmd/devd
modd looks like it has the advantage of only specifying this one, and specifying commands to be run when modd first starts up (autorun only has one type of command that's run on startup and on file changes).
Not directly applicable here, because you need to work with what you have, but this kinds of stuff always reminds me of https://www.jwz.org/doc/cddb.html
Heh, I know what you mean. BTW, directly following that link from here gets you to jwz's wee joke about HN. You'll need to copy the link and paste it in a new tab to see the article.
I've been using this tool for a month and it's really great. A focused tool that does its job well.
The only caveat I got, and this is completely due to my inexperience with Go, is to not use `daemon: go run foo.go`, but to `prep: go build foo.go; daemon +sigint: ./foo`
Another good use is to restart webpack when a non-hot-replaceable file changes:
Great to hear. :) Modd was born because because I was trying to figure out how to add the ability to do a build step before livereload in devd. It soon became clear that quite a different type of tool was needed to do this well, and after a few iterations I settled on the current design for modd.
Here's a Java article describing its internals: http://www.javaadvent.com/2015/12/reactive-file-system-monit...