Currently the specs that are generated by flanders is for CLJ only because we use eval, and because I was thinking that we'd create the specs at runtime (which requires macros). CLJS has no reader nor does it have runtime macros.
However, I think that we can define the specs at compile time (still based on flanders definitions). As long as we got rid of eval, that should work in CLJS. We could have a flanders.spec-sexprs NS that creates sexpr srings for defining the specs. The consuming CLJS code could use a macro (in a CLJ NS) to create and def the spec sexprs at compile time.
If we did this, we might have both flanders.spec and flanders.spec-sexprs outputs. The .spec NS could reuse a lot of the code in spec-sexprs, and it would work just like it does now. The .spec-sexprs would never def any spec, it would just return the code to do so as a seq of strings.
Currently the specs that are generated by flanders is for CLJ only because we use eval, and because I was thinking that we'd create the specs at runtime (which requires macros). CLJS has no reader nor does it have runtime macros.
However, I think that we can define the specs at compile time (still based on flanders definitions). As long as we got rid of eval, that should work in CLJS. We could have a flanders.spec-sexprs NS that creates sexpr srings for defining the specs. The consuming CLJS code could use a macro (in a CLJ NS) to create and def the spec sexprs at compile time.
If we did this, we might have both flanders.spec and flanders.spec-sexprs outputs. The .spec NS could reuse a lot of the code in spec-sexprs, and it would work just like it does now. The .spec-sexprs would never def any spec, it would just return the code to do so as a seq of strings.