make.ts
Up Enter Up Up Enter Up Up Up Enter
Sounds familiar? This is how I historically have been running benchmarks and other experiments requiring a repeated sequence of commands — type them manually once, then rely on shell history (and maybe some terminal splits) for reproduction. These past few years I’ve arrived at a much better workflow pattern — make.ts . I was forced to adapt it once I started working with multiprocess applications, where manually entering commands is borderline infeasible. In retrospect, I should have adapted the workflow years earlier.
The Pattern Use a file for interactive scripting. Instead of entering a command directly into the terminal, write it to a file first, and then run the file. For me, I type stuff into make.ts and then run ./make.ts in my terminal (Ok, I need one Up Enter for that). I want to be clear here, I am not advocating writing “proper” scripts, just capturing your interactive, ad-hoc command to a persistent file. There are many benefits relative to Up Up Up workflow: Real commands tend to get large, and it is so much nicer to use a real 2D text editor rather than shell’s line editor.
If you need more than one command, you can write several commands, and still run them all with a single key (before make.ts , I was prone to constructing rather horrific && conjuncts for this reason).
, I was prone to constructing rather horrific && conjuncts for this reason). With a sequence of command outlined, you nudge yourself towards incrementally improving them, making them idempotent, and otherwise investing into your own workflow for the next few minutes, without falling into the YAGNI pit from the outset.
At some point you might realize after, say, running a series of ad-hoc benchmarks interactively, that you’d rather write a proper script which executes a collection of benchmarks with varying parameters. With the file approach, you already have the meat of the script implemented, and you only need to wrap in a couple of fors and ifs.
Finally, if you happen to work with multi-process projects, you’ll find it easier to manage concurrency declaratively, spawning a tree of processes from a single script, rather than switching between terminal splits.
Details Use a consistent filename for the script. I use make.ts , and so there’s a make.ts in the root of most projects I work on. Correspondingly, I have make.ts line in project’s .git/info/exclude — the .gitignore file which is not shared. The fixed name reduces fixed costs — whenever I need complex interactivity I don’t need to come up with a name for a new file, I open my pre-existing make.ts , wipe whatever was there and start hacking. Similarly, I have ./make.ts in my shell history, so fish autosuggestions work for me. At one point, I had a VS Code task to run make.ts , though I now use terminal editor. Start the script with hash bang, #!/usr/bin/env -S deno run --allow-all in my case, and chmod a+x make.ts the file, to make it easy to run. Write the script in a language that: you are comfortable with,
doesn’t require huge setup,
... continue reading