API hooks during restart for deno run --watch
Hello! I thought it would be super fun to further minimize repetitive tasks while manually testing a work-in-progress app during early and active development. So far, I love that the deno watcher can react to source file changes!
One of my goals would be to automate mundane tasks in order to observe feedback faster as I: learn deno, prototype ideas, experiment with browser APIs / paradigms (e.g. saving state on document hide via session storage), etc.
Specifically, I would love the ability to programmatically reload a specific Chrome tab (e.g. via puppeteer), anytime that I save code changes. So far (after about a couple days of wrestling with Bash scripting), I've got a crude working prototype for this use case.
Yet, I can't help but wonder if there was a simpler way all along that I haven't discovered yet in my research attempts.
I would absolutely love an idea like
* process initial start
* process initial fail
* process about to restart
* process successfully restarted
* process failed to restart
* end of watching (e.g. upon a
I imagine such an idea (or something similarly functional) would be simpler to understand, less brittle to maintain, and more functionally capable than a Bash 3.2 script that extracts a
For those curious enough, here is what my current Bash script does:
* Makes an auxiliary fifo pipe
* Spawns a new Chrome instance
* as a background child process
* using a hard-coded executable path (already installed on my computer)
* with a
* redirecting std{out,err} into the fifo pipe
* Awaits for Chrome's debug URL to appear
* via blocking reads on the the fifo pipe
* by pattern matching for a line that starts with
* and additionally extracting the websocket URL's hostport
* Spawns my custom puppeteer script with Chrome's debug URL as an argument
* as a background process
* via a
*
*
* that roughly does
* Sends a
One of my goals would be to automate mundane tasks in order to observe feedback faster as I: learn deno, prototype ideas, experiment with browser APIs / paradigms (e.g. saving state on document hide via session storage), etc.
Specifically, I would love the ability to programmatically reload a specific Chrome tab (e.g. via puppeteer), anytime that I save code changes. So far (after about a couple days of wrestling with Bash scripting), I've got a crude working prototype for this use case.
Yet, I can't help but wonder if there was a simpler way all along that I haven't discovered yet in my research attempts.
I would absolutely love an idea like
deno run -A --watch --watcher-debugging-port=<port> --watch-autostart=<true|false> app.tsdeno run -A --watch --watcher-debugging-port=<port> --watch-autostart=<true|false> app.ts that could maybe expose a WebSocket server on the debugging port for clients to listen to watcher events, perhaps including but not limited to:* process initial start
* process initial fail
* process about to restart
* process successfully restarted
* process failed to restart
* end of watching (e.g. upon a
kill -TERMkill -TERM)I imagine such an idea (or something similarly functional) would be simpler to understand, less brittle to maintain, and more functionally capable than a Bash 3.2 script that extracts a
ws://<...>ws://<...> URL and coordinates between background subprocesses for <...>/MacOS/Google\ Chrome<...>/MacOS/Google\ Chrome and deno run --watch <script-to-connect-puppeteer-and-serve-app-and-reload-page.ts>deno run --watch <script-to-connect-puppeteer-and-serve-app-and-reload-page.ts>.For those curious enough, here is what my current Bash script does:
* Makes an auxiliary fifo pipe
* Spawns a new Chrome instance
* as a background child process
* using a hard-coded executable path (already installed on my computer)
* with a
--remote-debugging-port=0--remote-debugging-port=0 and fixed value for --user-data-dir--user-data-dir* redirecting std{out,err} into the fifo pipe
* Awaits for Chrome's debug URL to appear
* via blocking reads on the the fifo pipe
* by pattern matching for a line that starts with
DevTools listening onDevTools listening on* and additionally extracting the websocket URL's hostport
* Spawns my custom puppeteer script with Chrome's debug URL as an argument
* as a background process
* via a
deno run --watchdeno run --watch with very granular permissions like*
--allow-env=PUPPETEER_PRODUCT--allow-env=PUPPETEER_PRODUCT*
--allow-net=:8000,"${ws_hostport?}"--allow-net=:8000,"${ws_hostport?}"* that roughly does
Deno.serve({ onListen(...) { ... puppeteer.connect({ browserWSEndpoint, ... }) ... /* find or create browser page; goto App URL */ } })Deno.serve({ onListen(...) { ... puppeteer.connect({ browserWSEndpoint, ... }) ... /* find or create browser page; goto App URL */ } })* Sends a
kill -TERMkill -TERM to the puppeteer script if Chrome process finishes earlier than usual (e.g. if I manually quit Chrome)
