

ClojureScript Builds, Rebooted - skrblr
http://adzerk.com/blog/2014/11/clojurescript-builds-rebooted/

======
weavejester
Boot looks interesting, but replacing an immutable data structure with side-
effectful functions feels like a step in the wrong direction.

~~~
michaniskin
The main reason why build tools exist is to perform transformations on a file
set. The vast majority of the things build tools do that are useful are side
effects.

These "side-effectful" functions are basically transducers; the reduction is
performed on the file set instead of a sequence. They are mostly stateful
transducers, but this does not fly in the face of functional programming. The
opposite, in fact! They facilitate separation of concerns in a way that an
immutable but global configuration map cannot.

~~~
weavejester
It's true that you need to interact with the filesystem eventually, but the
longer that can be deferred, the more complexity can be avoided.

Ideally I'd want to construct a functional data structure that describes my
build process, and at the end pass it to a side-effectful function to produce
a change to the filesystem. Boot appears to be side-effectful from the get-go,
but perhaps I'm mistaken about how it operates?

~~~
michaniskin
Sorry, I should have mentioned that while boot, like any JVM build tool, does
begin and end with the class path, we have spent an enormous amount of time
experimenting with ways to mitigate the effects. We ended up with a system
that provides many of the benefits of immutability while still living in the
real world where files actually exist.

Here are some of the things boot provides:

1\. We have "pods", which are separate Clojure runtimes in isolated class
loaders in which you can evaluate expressions. The actual building occurs in
these things. They are lexically scoped and can have a different class path
than the main Clojure runtime where your build pipeline runs.

2\. Files emitted during the course of the build are created in temp dirs
managed by boot. There are a few different kinds of these temp dirs, one of
which is lexically scoped. We also have temp dirs that are effectively
immutable from a given task's point of view (we use a copy-on-write scheme to
achieve this).

3\. We make liberal use of hard links and directory syncing to emulate
immutability wherever we can. Boot provides a kind of structural sharing with
these hard links that really makes the pain of dealing with files go away.

4\. We put a great deal of thought into how artifacts flow through the build
pipeline, and how tasks that don't know anything about each other can
cooperate to work on these files.

This is the most interesting part of boot for me, and I'll be making a
complete writeup about it soon.

~~~
weavejester
It sounds like Boot has had a lot of thought put into it, and I certainly
welcome the idea of effectively immutable directories.

But it also looks like Boot dives head first into I/O, when I'd prefer a build
tool that is a little more circumspect about complexity. While I welcome
competition to Leiningen, and I'll certainly keep an eye on Boot, my initial
impression is that it's heading in the opposite direction to where I'd want a
build tool to go.

------
lynndylanhurley
How will this work with tools like figwheel [1] and austin [2]?

1\. [https://github.com/bhauman/lein-
figwheel](https://github.com/bhauman/lein-figwheel)

2\. [https://github.com/cemerick/austin](https://github.com/cemerick/austin)

~~~
michaniskin
The post was a demonstration of exactly that: cljs incremental builds with
live-reload and cljs browser repl.

