Old and new workflows
My dev workflow used to look like this:
- Write some code and save it
- Change to my Terminal window
- Up-arrow to find my command to run unit tests (typically
make test) - Press Enter
- Wait for tests to run and examine test output
This worked pretty well, but was a lot of manual steps when you figure that I did this dozens (hundreds?) of times per day. That’s a lot of energy spent doing the same thing over and over again.
Then I ran across Julia Evan’s post on entr. entr monitors a list of files and when they change, can run any command you want. In my case, I have it run unit tests with: make test
My workflow thus becomes:
- Run command in my terminal:
git ls-files | entr -csr 'make test' - Write some code and save it
- Wait for tests to run
- Wait for tests to run and examine test output
Rather than executing three steps (change windows, up-arrow to make test, press Enter) every time I change my code, I now execute zero.
This dramatically reduces the friction of changing my code and running its unit tests and makes it even easier to get immediate feed back on my test.
This might seem like a small thing, but it’s not. It shortens the Change -> Feedback loop and takes so much friction out of running tests.
I’ve been using this technique for over a year and am still so pleased with it.
Examples
You tell entr the file(s) to monitor by passing them in via stdin.
Examples:
git ls-files | entr ...ls file1 file2 file3 | entr ...ls *.py | entr ...find . -type f -name '*.go' | entr ...
Common arguments
entr supports a number of arguments, but I typically use these three:
-c-> clear the screen before running my command-s-> runs your command in a separate shell-r-> restart your process (if it’s a long running process like a server)
-r above hints at this, but you can even use entr to run and then restart a server if any of the monitored files change. This can be really useful if you’re making code changes and want to see their effect when they are run.
Using entr on macOS
If you’re entr on a Mac within a container (as I am), you’ll need to set the environmental variable ENTR_INOTIFY_WORKAROUND to have it work reliably. This is apparently due to incomplete inotify support by Docker. I set it with exprot ENTR_INOTIFY_WORKAROUND=1 in my Dockerfiles and it works perfectly after that.
I hope you’ve enjoyed learning about entr with me. For an investment of under an hour to learn it, it’s paid it back many times over.