Just so a smoother-brained fellow like myself can understand, and to prevent me from getting too excited by an incorrect interpretation, could you elaborate on what this can or cannot do? Or examples of what kind of debugging can actually be done? In my case, I'm new to clj/s, and wish I could combine the utility of the chrome devtools/inspector, with actual clj code, instead of having to write js code in the chrome inspector console. Would this let me scratch that itch? If it's not obvious, I'm very excited about what you're working on and want to thank you for it!

Based on the current state: Can: • load into any inspector port, establishing a goog.base/cljs runtime if needed • tunnel source-file loads through inspector port, to remove need for networking • dispatch inspector connection to extensions, that may also need the capability to block/debug the JS thread during development Can not: • track local-variable renames in case of shadowing • provide compatibility for cider debugger • interactively select or switch JS pages/contexts Note: https://github.com/tatut/clj-chrome-devtools already let's you remote control js runtimes to your heart's content, and the cljs compiler already can compile forms on the fly. cdp-repl is just a composition of these, packaged as a cljs repl-env, which abstracts the sending and receiving of repl forms. There are already many specialized and composable repl-envs for different purposes. This one is novel in 2 ways: a) it doesn't need XHR or fetch; b) it can allow JS to make blocking calls into the repl host