When used with `watch` only run tests with changes

[crisptrutski]

For non-test files, could leverage namespace dependency graph somehow

[martinklepsch]

For this and various other things it would be useful if boot-cljs somehow
exposes the dependency graph. Most obvious would be through the fileset as
an edn file I guess.

cc @Deraen

On Tue, 22 Dec 2015 at 22:30, Chris Truter notifications@github.com wrote:

For non-test files, could leverage namespace dependency graph somehow

—
Reply to this email directly or view it on GitHub
#26.

[Deraen]

Boot-cljs already exposes the dependency order as metadata on files on fileset.

https://github.com/adzerk-oss/boot-reload/blob/master/src/adzerk/boot_reload.clj#L22

Though I'm not sure how good idea using this is. I'm planning on eventually replacing the logic in boot-reload and possibly removing the current metadata from boot-cljs when boot-reload doesn't use it anymore. If someone has a use case, it's possible that boot-cljs will exposes some metadata.

There is also Cljs issue about providing proper API for retrieving the dependency graph: http://dev.clojure.org/jira/browse/CLJS-1407

For this use case, would it be enough to just check the changed files?

[crisptrutski]

For this case we're working backwards through the requires, so can't just analyse the changed files (if I'm understanding you correctly)

For a first implementation users could just save the test files themselves to rerun, seems OK for TDD (perhaps you meant this rather?)

Don't need the entire graph, just a map from (potentially a subset of) test namespaces to their transitive dependent namespaces within the source paths (flat is OK). It may be worth the memory/speed savings just building this structure directly?

[crisptrutski]

@Deraen thinking of tackling this, but it requires access to the compiler state / env for each build (or even just cljs-dependency-graph values would suffice). Unfortunately :dep-order is not sufficient, we need the actual require edges.

Would you take a PR adding a map of {id state} or {id graph} to the fileset?

Alternatively a way to provide a hook/callback to run after any compilation This could be something like [k(eyword) f(unction)] pair(s), and the fileset would add a map of {id (f env)} as metadata with the key k. Since the value needed is much smaller than cljs-dependency-graph (a shallow map of each namespace to the collection of test namespace that requires it, perhaps transitively). This could perhaps even be shrunk even further, with only just-changed files as keys.

Or perhaps this data can be computed later from finding analysis cache files in the fileset in a later task, and parsing that? Would be nice not to load boot-cljs with more concerns.

One issue that just occurred to me is there's a stale data issue - by the time you have the latest dependency map, you've already compiled the js for the code-generated test runner which contains the test namespaces that must be rerun. At worst we could just do one more round of generate and compilation, in the caess where there's mismatch. This is likely a vanishingly uncommon case in a TDD workflow, so the extra time would acceptable.

[Deraen]

Would be nice not to load boot-cljs with more concerns.

Yeah, that's my concern also.

Instead of using analysis cache files, one possibility would be to just read the cljs source files similarly to what Cljs compiler does: (-find-sources source all-opts) where source is something which implements cljs.closure/Compilable. It doesn't really parse the whole files but only reads the namespace forms from start of each file and returns list of maps which can then be processed futher: https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/closure.clj#L1890-L1892

This could be eventually provided through Cljs public API (CLJS-1407).

Do you have some test project with boot-cljs-test? I have some ideas I could try. Or maybe I'll add tests to Saapas :)

One problems with reading sources or cache files is getting access to temp dirs created to Boot-cljs.

[Deraen]

If it's enough to access Cljs options (input directory etc.) inside cljs-test handler, the selected options could be included as metadata on fileset object (on the object itself, not per file). This solution is already used by Perun.

[crisptrutski]

Sounds interesting! Don't have any substantial open source test suites to share - but like the idea of tests in Saapas 😄 👍

The solution you describe now sounds the most stable - no need to "do over" the analysis when the topology changes, because we can run this before the boot-cljs step

[Deraen]

I have now one test in Saapas and I'll grow it after we get other issues sorted out.