There is a need more complex build scripts for ClojureScript. It would be nice to have a minmal interface and method for composing these scripts. Somehting like:
(-> (watch-cljs ["src"])
(watch-sass [""])
(compile-sass)
(watch-css [""])
(mark-macro-affected-source build-options)
(compile-cljs build-options)
(cljs-browser-repl)
#_(fighweel-browser-connection)
#_(figwheel-browser-repl)
(ambly-repl))It is not lost on me that this is similar to what boot currently does. I have nothing against Boot, it would just be nice to have something that was neither tied to lein or boot that allows us to create and share building tools.
This system would not require buy-in just adhearance to a simple interface.
What should this interface look like?
Right now I'm leaning towards a ring-like functional interace where individual components can use core.async or other methods to handle the nastiness of this type of async build work.
Things to consider.
-
It would be nice to be able to create these composable flows and perhaps explicitely start and stop them.
-
I am also leaning toward a message based flow. Where the current component either recieves and operates on the message eventually forwarding it or passes it on untouched.
Tiny example:
(defn compile-cljs [source-paths build-options]
(fn [f]
(fn [signal]
(f (if (= [:cljs-changed] signal)
(do (cljs.build.api/build source-paths build-options)
[:cljs.build/cljs-compiled {:data ...}])
signal)))))I'm just putting this out there. This idea has been in my head for a year and I'd like to break figwheel down into parts that can be more easily reused.
So we may be looking at this differently. Upstream tasks are just firing events saying that "this happened" not intending or requiring further action, downstream tasks are just deciding to act if they need to.
I see FileSets as a state that says "now we have this data". Which is cool and interesting to think about. Everything that is expressed has to fit into this object. "Notes for the next guy." FileSets further arrange this around the idea of files that have changed, and this is not the only thing that I would like to express.
"Notes for the next guy" requires that you run predicates over the data to discern if such and such happened.
FileSets aside. This comes down to messages and/or state. I think I understand the generality of threading state down through the functions. But events and event listeners are a powerful means of general expression as well. Also, a single message chain where one can filter, reduce messages etc.
There is really no coupling difference in a threading a state (need to inspect and understand the shape of the state) or a message (need to know the name and content of the message). They are both general, meaning it is up to the next consumer to understand what is going on in this world.
I think messages have an advantage in that they express things that have occurred.
This is a common problem with an atom listener. In the listener we are trying to divine an occurrence that leaves an indistinct or difficult to trace mark on the state.
A compiler-component can emit "compile-start", "compile-warnings", "compile-errors", etc. These are better communicated as messages I think.
Say that we have something that is connected to the browser and a message that originates in a server-side component and all these messages are sent to the browser and on the browser we have a similar chain that extends the server side one.
But I can see how both worlds would be helpful. So maybe a full on Monad is a way to go. It's nice to have threaded messages and state.
But I do want something small, understandable, that invites people in. We aren't doing anything too crazy here. If things need to be expressed that can't be expressed this way nothing prevents folks from writing a script to do it.