Standardise task options

[magomimmo]

I can't really understand why both boot-cljs-test and boot-test run all project namespace when the -n option is not set to a specific test namespace. Is it not a waste of time, especially in a TDD workflow scenario?

I know that to test private symbols you need to test them inside the defining namespace, but I never met a source code doing that. On the contrary, most of the time people create a test directory layout like the following:

• test
  • clj
  • cljs
  • cljc

where all the application tests are confined. IMHO it would be better to have an option to say where the test namespaces are located and interpret the absence of the -n option as "run all the namespace in the test directories. Is my opinion so wrong?

[crisptrutski]

The noise and extra time spent testing extra namespaces is certainly frustrating, and boot-cljs-test in particular fails by pulling in all sorts of completely random namespaces even outside the project - eg. clojure.string.

The kicker is that these tools are oriented around the classpath, and it's not straightforward to discriminate based on something like a "test" directory - that information has been lost by the time these tasks run.

Also as you mention, there's no restriction about which files you define tests in - there are even things like with-test in clojure.test to make inline testing easy. But I agree the separate tests are far-and-away the mainstream, and worth favouring (just not being limited to).

Since your interest is portable suites, let's consider solutions that don't involve changing boot-test for now. It also supports excludes, a blacklist of literals, but that's not really useful since we'd need to use namespaces anyway (or generate A LOT of excludes).

• We can build a list of namespaces directly from filesystem directories (eg. "test")
• We can ignore namespaces like test-utils by limiting to names like *-test

Generic functions like these are simple, composable and portable, so I'll happily add them here and see if they have legs and fit your use case.

Would also take PRs here to:

1. Also support excludes for parity
2. Replace the doo-based test namespace inference something more conservative like boot-test.

But not interested in those partial solutions enough to bother implementing myself.

[magomimmo]

Thanks for your answer. I'll think about it within the next few days for better understanding what would be a clean solution.

[magomimmo]

The noise and extra time spent testing extra namespaces is certainly frustrating

yes, it is, especially within a TDD workflow. I'm not a TDD practitioner, but I know they would judge unacceptable anything longer than 1 or 2 seconds.

• We can build a list of namespaces directly from filesystem directories (eg. "test")
• We can ignore namespaces like test-utils by limiting to names like *-test

Sure, I could do all of this from the outside of test and test-cljs tasks, but is not the cleaner solution.

Also support excludes for parity

what does it mean excludes for parity ?

thanks
mimmo

[crisptrutski]

Sure, I could do all of this from the outside of test and test-cljs tasks, but is not the cleaner solution

The value of putting in a library is that the approach could mature and then find it's way into the tasks themselves if it proves popular and reliable. The code is just complex enough to be a chore adding to every project.

Also support excludes for parity

Just mean adding excludes param to test-cljs task, to match test

The biggest issue with a "solve via computing task arguments" approach is the boot watch case - not sure how to build a pipeline that would recompute downstream task options. Not sure it's even possible!

[martinklepsch]

The biggest issue with a "solve via computing task arguments" approach is the boot watch case - not sure how to build a pipeline that would recompute downstream task options. Not sure it's even possible!

You could write a task that scans the fileset for test namespaces and puts them into a list inside an edn file. This way they would be recomputed by watch and downstream tasks could pick them up.

Maybe this creates some UX challenges but I think this is how you'd do it with Boot.

[magomimmo]

On Dec 17, 2015, at 12:49 PM, Chris Truter [email protected] wrote:

Just mean adding excludes param to test-cljs task, to match test

ok
The biggest issue with a "solve via computing task arguments" approach is the boot watch case - not sure how to build a pipeline that would recompute downstream task options. Not sure it's even possible!

you are right. But or I do not touch test and test-cljs and I accept the tradeoff of restarting the JVM any time I have to add a new test-namespace, or I have to extend both test and test-cljs to cover that usa case.
—
Reply to this email directly or view it on GitHub #23 (comment).

[magomimmo]

On Dec 17, 2015, at 12:51 PM, Martin Klepsch [email protected] wrote:
. Not sure it's even possible!

You could write a task that scans the fileset for test namespaces and puts them into a list inside an edn file. This way they would be recomputed by watch and downstream tasks could pick them up.

Yes, this is an option. Still thinking about the cleanest one (and I have to study boot source code as well). I’m define the requirements top-down. Too many time I saw people doing the opposite, bottom-up. From the first look that I gave to boot source code it seems to me that there is something missing in the fileset record...
—
Reply to this email directly or view it on GitHub #23 (comment).

[crisptrutski]

@martinklepsch my issue with that approach is that downstream tasks need to know about these files, it's not really "open/closed". Would be interesting if there was some way to graft over a task's options. I guess this could be done with a task decorator? Or maybe this is a terrible idea 😄

[crisptrutski]

Something like this:

(defn wrap-task [task-fn args-fn]
  (fn [next-task]
    (fn [fileset]
      (let [args (args-fn fileset)
            task (task-fn args)]
        ((task next-task) fileset)))))

Could wrap that around test task to compute :namespaces. Could even skip the edn file, and look directly at the test directory.

[martinklepsch]

Not sure if I understand your decorator suggestion but you can supply
functions as task options then the supplied function could be called to
return list of namespaces. Maybe this would already provide enough
dynamic-ness?

On Fri, Dec 18, 2015 at 12:36 PM Chris Truter [email protected]
wrote:

Something like this:

(defn wrap-task [task-fn args-fn](fn [next-task]
%28fn [fileset]
%28let [args %28args-fn fileset%29
task %28task-fn args%29]
%28%28task next-task%29 fileset%29%29%29))

Could wrap that around test task to compute :namespaces. Could even skip
the edn file, and look directly at the test directory.

—
Reply to this email directly or view it on GitHub
#23 (comment)
.

[crisptrutski]

Have updated the PR to use the wrap-task idea, which turns out to work well enough. Maybe with a bit of polish this is useful duct tape.

supply functions as task options

Do you mean changing tasks so that they have an additional "function" version of given argument, eg. :namespaces-fn?

[crisptrutski]

@magomimmo let me know what you think about this setup for opting into the kinds of conventions you suggested

[crisptrutski]

Looking at https://github.com/seancorfield/boot-expectations which has just been released, it's using an :include and :exclude as regexes approach, but using the input fileset. Elegantly implemented.

A note on wrap-task: trying it out with auto watch, it's too slow. I don't think there's caching between CLJS compiles when parent task is recreated.

[magomimmo]

@crisptrutski your with-ns function is smart, but is something unusual to be used by a boot user while composing tasks in the simplest possible way within the build.boot file. In some way, it’s exposing the user to an internal problem of the tasks components she’s using.

from a user point of view I would expect:

a) the test clj task a boot built-in task, as leiningen does (this regards boot-test), even because clojure.test is not an external lib you have to add to the depenendencies to use it and clj test does not need an external testbed engine to run tests into. The need to add a boot-test dep is an incidental complexity and the boot-test should be aboserbed in the boot’s predefined tasks.

b) by default, the test and the test-cljs tasks should consider only project's namespaces containing tests, not all the project’s namespaces. I What a user wants to test are her/his own namespaces only, not the ones coming from the dependencies as well. Any deps should has its own test. So, by default I would filtered all the namespaces starting with the name of the proejct (e.g. boot-cljs-test-example.*). This way you’ll cover also the very rare cases in which you define inline tests or tests on private symbols in your own namespaces.

I know that run-all-test from the clojure.test namespace by default considers all namespaces as well. My very personal opinion is that this is wrong too.

http://blog.jayfields.com/2010/08/clojuretest-introduction.html http://blog.jayfields.com/2010/08/clojuretest-introduction.html

What I would like is something like this:

1. boot test

Takes into account all namespaces defined in the source-paths only (I’m still have to understand why someone uses resource-path for cli source code, which it’s misleading.

2. `boot test-cljs

as above

3. it’s funny to see a -f option in tests task to cover the very rare case in which I want to test few symbols only. If I have to do that, I’ll probably do in the REPL. I would eventually use the -f option to filter namespaces, not symbols in the namespaces.

4. I would use the -f in the same way in test-cljs as well.

5. Is the exclusion option really useful?

6. I would introduce a -s option for parity with cljs task.

A very short note on

(defn ns-from-dir
  "Given a directory, return a list of the namespaces given by files within it."
  [dir]
  (->> (file-seq (File. dir))
       (map #(.getPath %))
       (filter src-file?)
       (map #(file->ns (relativize dir %)))))

Couldn’t been implemented as trandusers for speed?

I’ll take a look at the Sean solution you cited.

thanks a lot for you efforts and patience

[magomimmo]

@crisptrutski @martinklepsch I looked at the Sean cited task. It's very close to what I was thinking about. The only thing I still disagree with (but it's a very personal opinion to be discharged as erethic) it's the choice of not filter out any namespace which is not in source paths in the default scenario (when you call it without options). I would only use the namespaces directly defined in the project (they can be filtered with something like main-project-segment.*)

One more thing. there should be a way to keep the JS running in the auto mode (i.e. watch). Most of the time spent by running the test-cljs depends on creating a new engine instance (at least with phantomjs) and then to start it again. In a TDD scenario any second counts. But I have no clue about this, aside from this article:

https://medium.com/@sharetribe/faster-cucumber-startup-keep-the-phantomjs-browser-open-between-tests-81daed0159a9#.s7dyfkatb

this has to do more with doo that with test-cljs task

[crisptrutski]

your with-ns … it’s exposing the user to an internal problem of the tasks components she’s using.

Agree, I was just trying to present a "works today" solution include boot-test. The wrap-task experiment showed tasks can be made more dynamic from outside without too much fuss, but at the cost of complexity and potentially bad execution for some tasks.

the test clj task [to become] a boot built-in task

Would recommend taking this up directly on the boot-clj repo, as you’re out in the far colonies here :)

I don’t have a strong opinion on this either. Generators like tenzing and saapas give you the starting-kit, and it's nice to be able to take off battery packs when you don't need them.

Part of what put me of Leiningen is the “banana comes with gorilla and rainforest accessories” experience.

by default, the test and the test-cljs tasks should consider only project's namespaces containing tests, not all the project’s namespaces. […snip…] So, by default I would filtered all the namespaces starting with the name of the project [...snip...]

The grail of having the runner dynamically determine the tests using metadata and the power of clojure (eg. find just namespaces with test-vars, and names like the project), that gives the most power. Checking for tests via regexes or walking the AST seems absurd.

You'll want to campaign for extra power (regexes being the starting point) up at doo, even if still computing the namespaces from CLJ instead of CLJS. See bensu/doo#9

There are also libraries that skip out doo in the middle: https://github.com/infracanophile/boot-cljs-test

I don’t agree about making the use of the project name. This convention is broken too often in my experience. Prefer being explicit here, although respective the project boundary properly is a must.

I would eventually use the -f option to filter namespaces, not symbols in the namespaces.

Agree that having separate regexes for namespaces and vars is odd, and the option is most valuable on the namespace. Sifting particular vars out does make sense to me though. eg. when triggered by watch, rerun only tests that failed on last attempt, or all files if everything passed.

Would be great to just support including a var portion in the regex: eg. #”my-proj.*/integration-test”

Is the exclusion option really useful?

Yes I think so, some examples: filtering out slower tests, or tests for a different platform than you’re using (eg. *nix vs windows)

[talk about ns-from-dir] Couldn’t been implemented as trandusers for speed?

It could, although the initial file-seq needs to be built. I also think that the IO involved there will dwarf the cost of the intermediate seqs.

Actually leaning towards just using https://github.com/clojure/tools.namespace/blob/6b19f942802f3b35059bb4acfa4791ef1717b8a9/src/main/clojure/clojure/tools/namespace/find.clj#L79, which is slightly slower but handles more edge cases.

It looks even slower than my implementation, but I think that’s justified for the extra robustness.

[crisptrutski]

Thanks for putting a fire under this stuff, @magomimmo, there's a lot of room for improvement with this library. I don't have the luck of working with either Boot or CLJS at the moment, and I'm not even really keeping up with the communities, so this is a bit of a "repo under threat".

1. Reporting issues, giving feedback. Getting eyeballs on the code too
2. More hands in here, will happily give push to successful contributors
3. Moving the project to a more official position (eg. the boot org or merging into doo). Or finding a successor and I'll deprecate. From a quick search on Clojars though I can't spot any real competitor though (with comparable downloads)

As a writer I think you're especially qualified to help push any of these agendas 😄

[magomimmo]

Would recommend taking this up directly on the boot-clj repo, as you’re out in the far colonies here :)

nobody is farway when making such fundamentals contributions like you do.

Part of what put me of Leiningen is the “banana comes with gorilla and rainforest accessories” experience.

Myne was to have one JVM only and a more simple build file to be read

The grail of having the runner dynamically determine the tests using metadata and the power of clojure (eg. find just namespaces with test-vars, and names like the project), that gives the most power. Checking for tests via regexes or walking the AST seems absurd.

I agree on the details (regex are fragile). Here is a code snippet from Joe Fields article on this topic:

(defmethod report :begin-test-ns [m]
    (with-test-out
      (when (some #(:test (meta %)) (vals (ns-interns (:ns m))))
        (println "\nTesting" (ns-name (:ns m))))))

I don’t agree about making the use of the project name. This convention is broken too often in my experience. Prefer being explicit here, although respective the project boundary properly is a must.

See above. main project segment is very fragile. The above Jay Fields's code snuppet would be better.

Would be great to just support including a var portion in the regex: eg. #”my-proj.*/integration-test”

Sure. but the above code snippet seems to be the holygrail.

[magomimmo]

this is a bit of a "repo under threat".

you did great contributions. the availability of your lib is one of the reasons I started to take al look at boot.

As a writer I think you're especially qualified to help push any of these agendas

I'm confined in the colonies as you are :-), but I'll do my best. BTW, The boot community is very welcoming.

[crisptrutski]

Thanks for the kind words @magomimmo, much appreciated

[magomimmo]

you're impressive @crisptrutski and last night you even got a big fish from the deep water! Your test-cljs deserves attenction from the boot community.

[magomimmo]

@crisptrutski @martinklepsch: thanks so much for the slack session last night! You were amazing. That said, talking about standardization/ergonomics, if I may say something as a typical user, I would say that the triad of test, test-cljs and cljs tasks are too important for not beeing standardized. In some way I think that test-cljs, aside from its specific options, shuould offer the sum of the task and the cljs options.

thanks so much again!

[crisptrutski]

You're welcome! Not sure what you mean by task options though

[magomimmo]

A kind of harmonization between (most of the are already in place). Perhaps this is what you called parity somewhere.

boot cljs -h
...
Options:
  -h, --help                   Print this help info.
  -i, --ids IDS                Conj IDS onto the ids option.
  -O, --optimizations LEVEL    Set the optimization level to LEVEL.
  -s, --source-map             Create source maps for compiled JS.
  -c, --compiler-options OPTS  Set options to pass to the Clojurescript compiler to OPTS. 

boot test -h
...
Options:
  -h, --help                  Print this help info.
  -n, --namespaces NAMESPACE  Conj NAMESPACE onto the set of namespace symbols to run tests in.
  -e, --exclusions NAMESPACE  Conj NAMESPACE onto the set of namespace symbols to be excluded from test.
  -f, --filters EXPR          Conj EXPR onto the set of expressions to use to filter namespaces.
  -r, --requires REQUIRES     Conj REQUIRES onto extra namespaces to pre-load into the pool of test pods for speed.

and

boot test-cljs -h
....
Options:
  -h, --help                 Print this help info.
  -e, --js-env VAL           Set the environment to run tests within, eg. slimer, phantom, node,
                                 or rhino to VAL.
  -n, --namespaces NS        Conj NS onto namespaces whose tests will be run. All tests will be run if
                                 ommitted.
  -s, --suite-ns NS          Set test entry point. If this is not provided, a namespace will be
                                 generated to NS.
  -O, --optimizations LEVEL  Set the optimization level to LEVEL.
  -o, --out-file VAL         Set output file for test script to VAL.
  -c, --cljs-opts VAL        Set compiler options for CLJS to VAL.
  -x, --exit?                Exit immediately with reporter's exit code.

and probably I would add boot-expectations as well to the club.

[crisptrutski]

@magomimmo I think you'll be happy with the latest SNAPSHOT:

> boot testing test-cljs

Writing clj_test/suite.cljs...
Writing output.cljs.edn...
Compiling ClojureScript...
• output.js
Running cljs tests...
Testing boot-cljs-test-example.lib-test
Running slow test 5...
Running slow test 4...
Running slow test 3...
Running slow test 2...
Running slow test 1...

Testing boot-cljs-test-example.app-test

Ran 3 tests containing 7 assertions.
0 failures, 0 errors.

As you can see, no non-test namespaces and no 3rd part deps. Will prepare a stable release with this after it's seen a bit more use.

Commandeering this task for the standardisation work, but would prefer to leave this as a contributor task 😉

[crisptrutski]

• Exclude: negative version of namespaces, applied afterwards
• Include: perhaps namespaces should be renamed?
• Filters: some way to perform finer grained checks on vars to test. Would require work on doo also.
• Requires: extra namespaces to include for tests. Perhaps an option for including JS files too

Also need to juggle the short-hand CLI acronyms for these tasks, so they're all exposed naturally.

[magomimmo]

@crisptrutski oh, yes. I love it. You rock! Yestarday I had an accident with my motorbike and I can't seat to much time in front of the computer, but I'll do my best for the standardization step. Thanks so much Chris, you really did a great job!

[crisptrutski]

Ouch! Glad you're OK - maybe a good time to try a standing desk 😄

[magomimmo]

@crisptrutski I just tried the new SNAPSHOT with the modern-cljs series. It works like a charm. This evening I'll consequently update the tutorial-16 of the series. It's really nice and fast too.
@martinklepsch test-cljs task works beautifully now, but the test task is not aligned with test-cljs behavior because his does not filter out the project namespaces without any test in them. what do you think about that?
@crisptrutski I should try a bed desk too!

[magomimmo]

ops, I did not note the new -u task option

[crisptrutski]

The -u task is a bit exotic, could be used to compile once and run in multiple environments. Doubtful anyone will actually use it though, a bit obscure too 😄

[martinklepsch]

test-cljs task works beautifully now, but the test task is not aligned with test-cljs behavior because his does not filter out the project namespaces without any test in them. what do you think about that?

An empty test namespace is probably an edge case? I guess I'd suggest to include it in the output to make to rules for inclusion simpler and more easy to understand. E.g. someone trying to figure out why his test namespace isn't being ran will have an easier time.

boot -d boot/greet:2015 greet

[crisptrutski]

@martinklepsch Easter eggs for xmas? Super geil 😉 ⛄

re: Confusing users with implicit exclusion - that's something I'm worried about too.

The current behaviour is actually even more crude and unexpected than you imagine - if no namespace pattern(s) or literal(s) are provided, boot-cljs-test defaults to using only those namespaces in the project whose names' end in -test. That filter magically disappears as soon as an argument is provided for namespaces.

So it wouldn't confuse the user in the scenario you describe, but when it does strike the user, I imagine intense infuriation 😱

On the other hand I really prefer not to analyse source code or compile it and check vars..

Perhaps a warning about the default convention in the case where no tests are found (this style of naming is probably all-in or all-out)

[magomimmo]

@martinklepsch happy holidays!!!! Your tasks was a great present. I appreciated a lot!

The current behaviour is actually even more crude and unexpected than you imagine - if no namespace pattern(s) or literal(s) are provided, boot-cljs-test defaults to using only those namespaces in the project whose names' end in -test. That filter magically disappears as soon as an argument is provided for namespaces.

So it wouldn't confuse the user in the scenario you describe, but when it does strike the user, I imagine intense infuriation 😱

One thing I learned with customers is the following: if you tell them about an issue before they discovered it by themselves, you'll never loose one of them.

A bold note in the README.md telling them about it could be enough?

On the other hand I really prefer not to analyse source code or compile it and check vars..

I try to use the trick by Jay Fields in the test task context:

(ns test-helper
  (:use clojure.test))

(defmethod report :begin-test-ns [m]
    (with-test-out
      (if (some #(:test (meta %)) (vals (ns-interns (:ns m))))
        (println "\nTesting" (ns-name (:ns m))))))

It works, but it's slow too when compared with passing namespaces with the -n option and even when compared with test-cljs without -n options.

I love the pragmatic solution by @crisptrutski. Ok, It's based on convention, but it works beautifully in a TDD scenario. Could be this convention create any issue in a continuous deployment scenario?

Perhaps a warning about the default convention in the case where no tests are found (this style of naming is probably all-in or all-out)

Or eventually let the user overwrite the standard convention with her own convention?

[magomimmo]

Hi @crisptrutski and @martinklepsch I think I completely misunderstood the test-cljs task. My goal was to run everything in a single JVM. I mean test-cljs internally uses cljs and I was thinking that by just substituting test-cljs to cljs in a composed task as follows

(deftask tdd 
  "Launch a TDD Environment"
  []
  (comp
   (serve :handler 'modern-cljs.core/app
              :resource-root "target"
              :reload true)
   (testing)
   (watch)
   (reload)
   (cljs-repl)
   (test-cljs :out-file "main.js" 
              :js-env :phantom 
              :namespaces '#{modern-cljs.shopping.validators-test})
   (test :namespaces '#{modern-cljs.shopping.validators-test})))

I could satisfy my objective to have everything running in the same JVM which means a TDD environment with a browser connected REPL as well.

Because I came from a previous execution of the following composed task

(deftask dev 
  "Launch immediate feedback dev environment"
  []
  (comp
   (serve ;:dir "target"                                
          :handler 'modern-cljs.core/app            
          :resource-root "target"                     
          :reload true)                            
   (watch)
   (reload)
   (cljs-repl) 
   (cljs)))

the cljs compilation was already there (in the target directory) and I did not note that what I reached is not what I wanted until, because of the new test-cljs SNAPSHOT, something went wrong and after having manually deleted the target directory I got the surprise. test-cljs compilation does not put its final output into the target directory.

My personal opinion, but I could be very wrong on that, is that test-cljs should be just the addition of the doo stuff to the standard cljs task, plus the few things that allows it to manually select/filter the namespaces the user want to test or automagically select the ones containing tests (I'm ok with the test convention, because is very fast).

Could my goal be satisfy by only using the cljs-options option of test-cljs? Is there a reason why cljs uses and edn hint in its task options, while test-cljs uses a code hint?

Sorry for my misunderstanding....

[crisptrutski]

The behaviour of test-cljs not populating the target directory is controlled by - u. The default of "don't update the fileset" was chosen to support cases of running cljs-test multiple times, or running cljs in addition. For example in a CI task you may want to run unit tests with :none on node, integration tests with :none on slimer, and and then produce an :advanced compiled artifact.

I'm not too sure what the interaction between cljs-repl and test-cljs would be, and that's perhaps another reason to separate the tasks.

There's no good reason why code was as the parameter type chosen, happy to take a change to that. In practice embedding non-trivial code in the CLI is uncommon, so they don't really differ much.

One thing to clarify is that test-clj do anything fancy with the cljs task. Mostly it just wraps the before-and-after aspect, with some safety wheels: handling the node case, and making the test runner the :main point, and ignoring other build profiles.

The prep-cljs-tests and run-cljs-tests are public, so you can combine them however you want. You'll want to provide separate build ids so that bootstrapping the app and bootstrapping the tests don't get conflated, and I think this will still result in cljs running the compiler twice though.

[magomimmo]

The behaviour of test-cljs not populating the target directory is controlled by - u.

awesome! you're really smart! I just checked it now and it works like a charm.

The default of "don't update the fileset" was chosen to support cases of running cljs-test multiple times, or running cljs in addition. For example in a CI task you may want to run unit tests with :none on node, integration tests with :none on slimer, and and then produce an :advanced compiled artifact.

I do not have an informed opinion on which used scenario of test-cljs could be the most frequent to be elected as the default one.

I'm not too sure what the interaction between cljs-repl and test-cljs would be, and that's perhaps another reason to separate the tasks.

uhm, it seems that the only problem I get in my case it happens when I run-tests and run-all-tests from within the CLJS REPL

cljs.user=> (t/run-tests 'modern-cljs.shopping.validators-test)

Testing modern-cljs.shopping.validators-test

Ran 1 tests containing 13 assertions.
0 failures, 0 errors.
WARNING: doo's exit function was not properly set
#object[TypeError TypeError: Cannot read property 'call' of null]
nil

and

cljs.user=> (t/run-all-tests)

Testing valip.core

Testing valip.predicates

Testing cljs.core

Testing modern-cljs.shopping.validators

Testing cljs.test

Testing cljs.pprint

Testing cljs.repl

Testing clojure.string

Testing valip.predicates.def

Testing cljs.reader

Testing modern-cljs.shopping.validators-test

Testing cljs.user

Testing clojure.template

Ran 1 tests containing 13 assertions.
0 failures, 0 errors.
WARNING: doo's exit function was not properly set
#object[TypeError TypeError: Cannot read property 'call' of null]
nil

But if you have an auto-test running and an active CLJS REPL I do not see the need of running a test inside the REPL.

There's no good reason why code was as the parameter type chosen, happy to take a change to that. In practice embedding non-trivial code in the CLI is uncommon, so they don't really differ much.

I'll think about it.

One thing to clarify is that test-clj do anything fancy with the cljs task. Mostly it just wraps the before-and-after aspect, with some safety wheels: handling the node case, and making the test runner the :main point, and ignoring other build profiles.

great!

The prep-cljs-tests and run-cljs-tests are public, so you can combine them however you want. You'll want to provide separate build ids so that bootstrapping the app and bootstrapping the tests don't get conflated, and I think this will still result in cljs running the compiler twice though.

I never tried to use in this way. I let you know if it will happen.

Thanks a lot again for you awesome work. You really rock!

[crisptrutski]

@magomimmo thanks for the motivation here, I've had some time to mull things over, and decided to make the push to support almost all the params (with the same shortcuts) for these other tasks. The only exception being an exotic boot test parameter, mentioned below.

Will release these changes in a breaking 0.3.0-SNAPSHOT build later this week.

boot-cljs

Support all options, with same names.

Also support parsing relevant .edn files behind the scenes to determine suite includes (ie. which tests) and compiler options.

boot-test

Support -n(amespaces) and -e(xclusions), but with regexes not symbols. Create PR to boot-test to similarly support regexes there.

Will take PR for #7 which would cover -f(ilters).

At this time do not consider -r worthwhile (just use .edn files or explicit suite file).

boot-cljs-test extras

-j --js-env (to be remapped from -e, which now clashes with `-e(xclusions)`)
-d --debug?
-x --exit?
-u --update-fs?

The -o(ut-file) parameter will be deprecated in favour of regular convention via ID(s).

The -s(uite-ns parameter will be removed (in favour of using ID(s) to determine this also) - to simplify multi-target builds.

[magomimmo]

Hi @crisptrutski, thanks for your hard work! I'm in the process of writing a new tutorial of the modern-cljs series...as I publish that stuff I'll get into this...keep doing all your great coding!

[crisptrutski]

Now that @Deraen is helping out, expect drastic improvements soon 😄

If you get your next iteration out before we release 0.3.0 perhaps just leave a footnote where you're arguments that will change? Thanks!

[mattfreer]

Hi @crisptrutski, just wondering are you still working towards release 0.3.0? As wondering if the --namespaces support is coming soon. Great work BTW.

[crisptrutski]

Hey @mattfreer - things came to a halt here based on a drastic shrinkage in my free time, lack of (perceived) urgency from users, and lack of external contribution.

I've dropped all the context on the 0.3.0 and can't recall what was left and where difficulties lie, if there was clear demand from more users for it's release I would definitely come out of hermitage though.

[crisptrutski]

@mattfreer

Microwaved the branch and releasing. Once it's seen some real world usage and I've updated the README will cut the 0.3.0 release with the current feature set.

Here's the new argument summary:

  -h, --help
  -j, --js-env
  -n, --namespaces
  -e, --exclusions
  -O, --optimizations
  -i, --ids
  -o, --out-file (deprecated)
  -c, --cljs-opts
  -u, --update-fs?
  -v, --verbosity
  -x, --exit?

The two options discussed above that did not make it (yet?)

 -f, --filters 
 -r, --requires

[mattfreer]

@crisptrutski thanks for the update, I'm using this branch now. Will let you know of any issues.

[mattfreer]

@crisptrutski namespaces and exclusions are working really nicely. Thanks!