@mitchelkuijpers what does your :http-handler do? what kind of assets? css I presume?

@thheller

(ns dev.test-handler
  (:require [ring.middleware.resource :as ring-resource]))

(defn not-found [req]
  {:status 404
   :headers {"content-type" "text/plain"}
   :body "Not found."})

(defn wrap-dir-index [handler]
  (fn [req]
    (handler
     (update-in req [:uri]
                #(if (= "/" %) "/index.html" %)))))

(def handler (-> not-found
                 (ring-resource/wrap-resource "public")
                 (wrap-dir-index)))

Also pre-compiled js

ah ok.

I can probably add an option for that as well.

I fixed the most annoying part first. all those damn macros in cljs.test

Cool, I also hadd to add a public dir or it wouldn't start up a http server

yes, I’ll make :http-root optional if :http-handler is set.

Nice

test are now queryable at runtime so you can probably build some fancy UIs out of that

just need to figure out how to configure all of this from a build perspective

Maybe give a test filename regex or something

{:target :browser
   :asset-path "/js/test"
   :modules {:common {:entries []}
             :devcards {:entries [atlas-crm.cards] :depends-on #{:common}}
             :test {:entries [atlas-crm.client-test-main] :depends-on #{:common}}}
   :output-dir "resources/public/js/test/"
   :compiler-options {:devcards true}
   :devtools {:http-port 8600
              :http-root "public" ;; We don't use this but our handler, but this makes shadow start a http server
              :http-handler dev.test-handler/handler
              :after-load atlas-crm.client-test-main/client-tests
              :preloads [shadow.cljs.devtools.client.hud devtools.preload]}}

needs way more options that just a regex though

shadow-cljs browser-test some-regexp can probably spin up a http server and open it

but how would you configure the :http-handler

shadow-cljs browser-test --test-match some-regexp --port 1234 --handler some.ns/handler --runner atlas-crm.client-test-main etc

you end up with a whole bunch of optionas

Hmm yes but most probably don't need the handler option

yes but what do you do if you need it?

do you ever use the karma test server thing?

Not really

I’m having a little troubling with shadow and namespaces

I keep getting filename violation statements

For example:

INFO: filename violation for ns paper.components.tooltip, got: cljs/paper/components/tooltip.cljs expected: paper/components/tooltip.cljs (or .cljc)

My shadow-cljs.edn file has :source-paths set to ["src/cljs"]

@colindresj thats odd, can you run shadow-cljs --cli-info?

Yeah

hmm

are you using :lein in your config? when embedding inside boot or lein their classpath will be used and :source-paths has no effect.

Yeah I am

The lein source path looks like this ["src/cljs" "src/cljc"]

somehow "src" ends up in your classpath as well

Let me dig around some more, the project.clj source paths vector looked different earlier (and had “src” in it)

btw its fine to use one source path. I put my cljs/cljc files into the same dir

Yeah, I keep going back and forth on which organizational style I prefer

Kind of related question: I’m currently using lein: true because I want to manage my clojure dependencies via project.clj (for cursive support)

Is the lein option a full opt-in, or can I just use lein for dependency management, and shadow for classpath building via the .edn file’s source path vector?

wow I never thought of that

currently the process is just launched through lein

but I could maybe just use it to get the classpath and then add the define :source-paths

you can however also use shadow-cljs pom to generate a pom.xml and use that for cursive

Oh sweet, didn’t realize that, will give it a try and see if it works

project.clj still gives you more features so its not 100%

It’s ok to have a shadow-cljs.edn file that just lists out :lein true and :builds ..., nothing else

Right?

as soon as cursive supports the new deps.edn I’ll add support for that which should remove some of the lein oddities

Awesome

yes, fine.

Thanks for the help

@mitchelkuijpers I’m fighting karma I don’t really understand what its doing

22 11 2017 19:36:28.744:WARN [web-server]: 404: /js/cljs-runtime/goog.debug.error.js
22 11 2017 19:36:28.744:WARN [web-server]: 404: /js/cljs-runtime/goog.dom.nodetype.js
22 11 2017 19:36:28.745:WARN [web-server]: 404: /js/cljs-runtime/goog.string.string.js
22 11 2017 19:36:28.747:WARN [web-server]: 404: /js/cljs-runtime/goog.asserts.asserts.js

I assume thats because of the include: false from your config

but when I add them it will add them to the page itself which just breaks

do I need to compile to one file only?

I seem to have the correct basePath but the js file can’t include anything else

it loads all the js weirdly, guess it really wants one file only

HeadlessChrome 0.0.0 (Mac OS X 10.12.6) LOG: '0 failures, 0 errors.'

22 11 2017 19:47:59.079:WARN [HeadlessChrome 0.0.0 (Mac OS X 10.12.6)]: Disconnected (1 times), because no message in 10000 ms.
HeadlessChrome 0.0.0 (Mac OS X 10.12.6) ERROR
  Disconnected, because no message in 10000 ms.

works, just needs some karma interop I guess

Ah you still need help @thheller

The include stuff is really annoying not sure why it works that way..

I think we really don’t want to run tests through karma at dev time

:test-dummy
  {:target :browser-test
   :output-dir "out/demo-test-dummy/public/js"
   :devtools
   {:http-root "out/demo-test-dummy/public"
    :http-port 8606}}

I have this for now

all the necessary hooks will be generated

still need a way to filter the namespaces but by default all namespaces that require cljs.test will be included

which probably won’t work for fulcro

It does use cljs.test under the hood

But does it simply inspects all the files?

no it must have a require for cljs.test itself to trigger this

but I guess the regexp you where using is more flexible

since its just about including the file in the build nothing more

Yes that is pretty much the only thing

Ahh now I see the browser-test target.. took me a while. I like that solution ^^

can specify :runner for a custom runner

still messing with the details but the test one I’m using currently looks like

(ns shadow.test.browser
  "generic browser test runner"
  (:require [shadow.test :as st]
            [shadow.dom :as dom]))

;; FIXME: implement custom reporter instead
(defonce log-node (dom/by-id "log"))
(when log-node
  (set-print-fn!
    (fn [s]
      (dom/append log-node (str s "\n")))))

(defn start []
  ;; (js/console.log "test env" @st/tests-ref)
  (st/run-all-tests))

(defn stop [done]
  (set! (.-innerText log-node) "")

  ;; FIXME: determine if async tests are still running
  ;; and call done after instead
  ;; otherwise a live reload might interfere with running tests by
  ;; reloading code in the middle
  (done))

;; not sure we need to do something once?
(defn ^:export init []
  (start))

could build something cooler but it’ll do for now

Ah cool, if I would build a custom runner then how would I get a hold of all the test namespaces?

With shadow.test somehow?

yep, shadow.test/tests-ref is an atom with all the tests

its all cljs.test as usual, the only thing I added is that deftest is registered at runtime

so you can query everything and don’t need a macro to do that

ie. it gets very easy to just run tests that were live reloaded

all this info was previously reserved for macro which is why anything involving tests also had to use macros

that takes care of that problem

much more flexibel

@mitchelkuijpers https://github.com/thheller/shadow-cljs/issues/57#issuecomment-346464244

Damn thats awesome will def try this out tommorow