entr VS swc-node

entr, A utility for running arbitrary commands when files change, yes basically this bad boy lets you run any command (or bunch of them as will cover in Makefile) when files change.

This is the same TUI app workflow I've settled on in other languages. Three notes:

- entr is a good livereload tool: https://eradman.com/entrproject/. I prefer to wrap the livereload scripts in a Makefile, under something like `make dev`.

- Managing layout arithmetic by yourself is a real pain. A widget abstraction like Bubbletea's is very helpful. Also, don't forget about weird Unicode characters (eg. emoji) potentially breaking width calculations.

- Since this follows the Elm architecture, consider storing your data the Elm way into one big, flat Model. Elm webapps turn into headaches when you split state among submodels. I think the same happens in TUI apps. I'm glad the author found a solution with a tree of models and message passing. But personally, I'd rather have a Model with 100 fields than the complexity of sumbodels.

Do I really need a whole Go library to do that? There must be a lighter or in other words Linux solution. I came across few solutions but not all had the capability to handle all types of directory changes. I wanted to be able to watch for file: create, edit, move, delete. For example entr doesn't rerun the command when a new file is added to the directory that is being watched.

entr ("Event Notify Test Runner"; GitHub), is a command-line tool written by Eric Radman that allows running arbitrary commands whenever files change.

tsx has very slow startup performance, I prefer https://github.com/swc-project/swc-node which is around twice as fast.

swc-node is much faster. No typechecking but you can have that running as a separate process with typescript in watch mode. Basically never have to wait for compiles or typechecking checking then.

fwiw swc has an official loader: https://github.com/swc-project/swc-node

I actually just switched my team's app over to use https://github.com/Brooooooklyn/swc-node for our Jest tests, but if we're going to upgrade to Next 12 it'd be nice to reuse whatever's included there.

I actually upgraded my team's Jest config to use https://github.com/Brooooooklyn/swc-node a few weeks ago. However, our Jenkins CI agents run RHEL7, and neither of the Linux binary targets would run. The `x64-gnu` binary needed a `GLIBC_2_23` symbol when only 2.18 was available, and the `x64-musl` binary had no `musl-libc` on the machine. I don't own the Jenkins agents, so I couldn't install other deps myself.

I ended up building `musl-libc` from source on another RHEL7 agent, committed the `.so` to our repo, and added that to the `LD_LIBRARY_PATH` in our Jenkinsfile, and actually got that working.

I did see some mentions that Rust could build to target an older GLibc ( https://kobzol.github.io/rust/ci/2021/05/07/building-rust-bi... ), so I'm curious if Next is going to use copies of SWC built that way for better compat or if it will require more workarounds on my part.

I'm very curious if the Next SWC binaries