Closed l3nz closed 4 years ago
In CLJS, we might require https://www.blog.nodrama.io/clojurescript-chaining-js-promises-previous-value/
As a simpler alternative, we might require https://cljdoc.org/d/funcool/promesa/4.0.2/doc/user-guide for CLJS.
I'm perfectly fine with the core.async dep. Maybe it could be a soft-dependency and only really needed if you actually want the long-running behaviour we're discussing. Probably mucks up the code with a bunch of does-async-namespace-exist introspection though.
An alternative for JS off the top of my head could be similar to a pattern you see in older pre-promise test runners. Since we don't worry about arity (ugh), the signature of the :runs
fn could be function (options, done) { doLongRunningStuff(done); }
with clj-matic providing the done
function. The long-running fn eventually invokes done(int)
to return control to clj-matic and exit. Because of JS's arity quirk, it's invisible to anyone who doesn't care.
It's ... convoluted and maybe not the best idea, but also I think I've seen the pattern a hundred times so at least it's got convention going for it.
Implemented ver 0.3.11
Is your feature request related to a problem? Please describe.
A number of people have a need to keep the JVM/JS up for a while (se e.g. #66 #83) after the cli run command stops.
Describe the solution you'd like
Your main function that implements the subcommand should return:
In the last two cases, wait until the promise is fulfilled or the channel has some data, and run System.exit with the value read from there.
Describe alternatives you've considered
I do not like the idea of having
core.async
as a mandatory dependency as I would only use core features.Not sure how and if this works in JS - Clojure promises don't work, it has its own
js/Promise
so the best pattern would likely becore.async
.