Fork me on GitHub
#shadow-cljs
<
2017-11-21
>
mitchelkuijpers13:11:22

Does anyone else run into this error after upgrading to the newest shadow-cljs?

mitchelkuijpers13:11:11

Ahh guess I need the newest core.async

mitchelkuijpers13:11:48

Nvm fixed by upgrading core.async

thheller13:11:04

@mitchelkuijpers oops, yeah upgraded a bit prematurely I guess. I really need to sort out those dep conflicts properly 😛

mitchelkuijpers14:11:41

it seems related that I have a nrepl open for that build

mitchelkuijpers14:11:51

Nope I made a boo boo in my code, but it seems to give errors like this when I screw up a macro

thheller14:11:19

hmm good to know, I’ll check it out

mitchelkuijpers14:11:08

And I have one more question, does shadow-cljs reloads all affected namespaces by default? Or can I turn that on somehow

mitchelkuijpers14:11:30

I have one ns that requires all tests files and I have to touch that before it reloads

thheller14:11:44

all directly affected namespaces, so only namespaces that have a require for the one that was changed

mitchelkuijpers14:11:39

Ah ok maybe I am doing something wrong then

mitchelkuijpers14:11:58

I have a xxxx-test -> tests-to-run -> client-test-main

thheller14:11:41

do you run all the tests all the time?

mitchelkuijpers14:11:18

We have a web renderer for the tests which probably just re-runs all tests or only the changed

mitchelkuijpers14:11:42

I think it only runs changed ones

mitchelkuijpers14:11:58

Maybe i just configured something wrong

thheller14:11:24

test is a somewhat special case since the test runner is constructed by a macro

thheller14:11:52

so technically it depends on all other namespaces but that is not properly expressed anyways

mitchelkuijpers14:11:53

Now it seems to work somehow, not sure what the deal is

mitchelkuijpers14:11:33

For us it is because we have one NS like this:

(ns atlas-crm.tests-to-run
  (:require
   atlas-crm.sample-spec
   atlas-crm.ui.impl.routing.path-spec
   atlas-crm.ui.impl.routing.linear-search-router-spec))

mitchelkuijpers14:11:08

And then this:

(ns atlas-crm.client-test-main
  (:require atlas-crm.tests-to-run
            [fulcro-spec.selectors :as sel]
            [fulcro-spec.suite :as suite]))

(suite/def-test-suite client-tests {:ns-regex #"atlas-crm\..*-spec"}
  {:default   #{::sel/none :focused}
   :available #{:focused :should-fail}})

mitchelkuijpers14:11:15

hmm yes maybe this macro breaks it

thheller14:11:21

yeah because of the indirection or tests-to-run, atlas-crm.client-test-main is not reloaded

thheller14:11:27

since it does not directly depend on the file

thheller14:11:52

I can add a “reload all” but in the past that was total overkill

mitchelkuijpers14:11:55

But it does not matter that client-test-main depends on tests-to-run?

thheller14:11:40

tests-to-run is probably reloaded, but def-test-suite macro probably inspects some analyzer data and is not reloaded to do that again

mitchelkuijpers14:11:18

Well it works good enough so not such a big deal

thheller14:11:45

why the indirection? why not put all the requires into the client-test-main?

mitchelkuijpers14:11:15

because I also have on for CI

mitchelkuijpers14:11:21

this way I can share them all

mitchelkuijpers14:11:41

(ns atlas-crm.CI-runner
  (:require
   atlas-crm.tests-to-run
   [doo.runner :refer-macros [doo-all-tests]]))

;; This file is for running JS tests via karma/node for CI server
(doo-all-tests #".*-spec")

mitchelkuijpers14:11:56

And figwheel does handle this case I think

thheller14:11:08

thats why I want to do a proper shadow-cljs test so you don’t have to write any of that

mitchelkuijpers14:11:11

But if there is better way them I am all ears

mitchelkuijpers14:11:19

Yeah that would be great

mitchelkuijpers14:11:38

which turns green when all tests pass

mitchelkuijpers14:11:11

But I rather have a good console runner with watch

thheller14:11:28

what I could probably do very easily is let you define the test runner

thheller14:11:57

and then use a regexp of some sort to construct the tests-to-run, or rather ensure that the namespaces are compiled/loaded properly

thheller14:11:37

coming up with a new test runner is a lot more work though

mitchelkuijpers14:11:41

Yeah maybe a bit too much work

mitchelkuijpers14:11:11

I think most also allow you to give the namespaces instead of a regex macro thingy

thheller14:11:33

hmm doo is lein specific it seems 😞

mitchelkuijpers14:11:20

The code I have sent I just compile with shadow and then run with karma

mitchelkuijpers14:11:37

this:

(ns atlas-crm.CI-runner
  (:require
   atlas-crm.tests-to-run
   [doo.runner :refer-macros [doo-all-tests]]))

;; This file is for running JS tests via karma/node for CI server
(doo-all-tests #".*-spec")

thheller15:11:31

how do you compile? I have never used karma, what does the config look like? and the build config?

mitchelkuijpers15:11:49

Hold on I will share it

mitchelkuijpers15:11:21

I have a karma.conf file in the root of the project with this in it:

module.exports = function(config) {
  config.set({
    browsers: ['ChromeHeadless'],
    basePath: 'resources/public/',
    files: ['js/ci/ci.js', {pattern: 'js/ci/cljs-runtime/**', included: false}],
    frameworks: ['cljs-test'],
    plugins: ['karma-cljs-test', 'karma-chrome-launcher'],
    colors: true,
    logLevel: config.LOG_INFO,
    client: {args: ["doo.runner.run_BANG_"],
    singleRun: true}
  })
};

mitchelkuijpers15:11:45

I added these deps:

"karma": "^1.7.1",
    "karma-chrome-launcher": "2.2.0",
    "karma-cljs-test": "^0.1.0"

mitchelkuijpers15:11:26

and then I do yarn exec karma start or if you are using npm npx karma start

mitchelkuijpers15:11:54

I have a config in my shadow-build.end like this:

:ci {:target :browser
               :asset-path "/base/js/ci"
               :modules {:ci {:entries [atlas-crm.CI-runner]}}
               :output-dir "resources/public/js/ci/"
               :devtools {:preloads [devtools.preload]}}

mitchelkuijpers15:11:04

with the above pasted CI-runner

mitchelkuijpers15:11:15

I will make a example later this week for fulcro users

thheller15:11:29

excellent. thx. I can definitely remove some of the boilerplate

mitchelkuijpers15:11:21

I see a that a lot fulcro users want to use npm deps but they are not quite sure how, hopefully a example will help

mitchelkuijpers15:11:37

ChromeHeadless is gold btw for CI

thheller15:11:15

(suite/def-test-suite client-tests {:ns-regex #"atlas-crm\..*-spec"}
  {:default   #{::sel/none :focused}
   :available #{:focused :should-fail}})

thheller15:11:31

that has a separate config I presume?

thheller15:11:38

the fulcro tests?

mitchelkuijpers15:11:53

No more cryptic phantomjs errors but sourcemapped errors in the console

mitchelkuijpers15:11:01

That is only to run the tests in the browsers

mitchelkuijpers15:11:23

With that you get the whole testing UI in the browser

mitchelkuijpers15:11:09

The config for that is:

:test {: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]}}

mitchelkuijpers15:11:19

I have one build for devcards and tests

thheller15:11:57

thx, that helps a lot.

thheller15:11:49

interesting that you’d use a custom handler without static files

thheller15:11:56

I would not have expected that someone would do that 🙂

thheller15:11:50

I’ll mess around with the testing stuff later, already have some ideas.

mitchelkuijpers15:11:07

Oh do you want the handler I needed it because some assets get server from the classpath