docs: how to run tests in watch mode

How to run tests in watch mode? I assume nodemon or watch is the answer ? Would love to see it included in examples as well.

cheers!

[lukeed]

Ok. I have created watchlist, which is my first pass at a CLI watcher. I will need some feedback in order to bring this to 1.0 – I know there are inconsistencies with Windows right now, but it’s late for me and I don’t currently have access to a Windows machine.

The watchlist usage is exactly as described earlier:

$ watchlist src tests -- npm test

The -- is important – it’s what separates watchlist from the command you want to run. It’s also what makes it possible to pass option flags to your command (uvu in this case):

$ watchlist src tests -- uvu tests -r esm -i fixtures

I will add a /docs item tomorrow for this.

[lukeed]

Right now I’d use something like watchexec – which would look like this:

$ watchexec -w src -w tests npm test

This (recursively) watches all files within the src and tests directories, rerunning npm test whenever there’s a change.

Although I might make my own watch CLI, which would look something like:

$ watch src tests -- npm test

It was suggested that uvu --watch exists, which I can’t say i’m 100% against, however, my hesitation with that (and it applies to my own watch CLI too) is that I still have to either (a) include all of chokidar; or (b) become familiar with the bugs/edge cases that chokidar solves & apply them to my own solution; © just rely on native fs.FSWatcher and hope for the best.

The benefit of a separate watch CLI is that those solutions/problems are contained to that module. If uvu --watch exists and proves to be buggy, then everyone inherits that code and it becomes a problem or it becomes big & burly. And there will be users (myself included) that never reach for that feature and it’s just there taking up space.

Sorry I’m ranting now – but to wrap up: I think all-in-one solutions can sometimes be nice, but especially in the JS community, I think we forget that CLIs are meant to be piped into and chained together. A CLI should do one thing well and be flexible enough to work with other CLIs – or at least self-contained so that it doesn’t matter how it gets invoked. Because of this, I’m definitely leaning towards a separate watch CLI, although I do understand the appeal of a uvu builtin.

---

Related: There was a little Twitter thread about this