Fork me on GitHub
#fulcro
<
2018-01-10
>
thheller11:01:02

@tony.kay thought about a bit and I think the implementation should be completely separate from the “API”

thheller11:01:49

the API just covers the tr macro and extracting the strings into the analyzer data

thheller11:01:15

your fulcro.i18n could provide a ITranslate implementation at runtime

thheller11:01:01

also enables tools like shadow-cljs to do everything completely transparent

thheller11:01:03

could maybe become part of CLJS itself since the API surface is very minimal

thheller11:01:16

but really doesn’t have to be so probably shouldn’t

thheller11:01:14

might be beneficial to have a generic i18n API for CLJS though

thheller11:01:40

oh I also rolled the trc,trf,tr macros into just tr. seems like an easier API

tony.kay17:01:43

@thheller I'll look it over. Surface reaction is that from a technical standpoint it seems solid. From a practical standpoint I need to think more about it. Not sure about the API change. The existing API is more clear I think, and it is more amenable to existing tooling which eases transition (e.g. what if only shadow-cljs implements your suggestion...then the "normal" cljs users lose i18n?

tony.kay17:01:24

The newer trf accepts named parameters or a single map...the named is for bw compat. Using a map turns out to be more practically useful.

tony.kay17:01:53

and given the map preference, a change in API to one call might better be:

(tr msgid {:cljs.i18n/context "optional context" ...other params...})

tony.kay17:01:33

context is rare, and ns aliasing makes it short to use

tony.kay17:01:48

that also makes the API easily extensible: just add more nsed kws to the options map

tony.kay17:01:03

that also makes it possible to pass additional info and custom options through to the string extraction layer.

tony.kay17:01:30

well...as literals at least..wouldn't want to deal with the resolve issues probably

tony.kay17:01:04

and I guess as far as API goes: trc and trf of Fulcro are just macros on top of this new macro...so bw compat is easy

tony.kay17:01:32

does shadow have an existing hook point to use this today? Or would it require new hooks?

thheller18:01:10

@tony.kay hmm I like the map instead of kw-args but what if the map is completely dynamic? we can’t extract :cljs.i18n/context then?

thheller18:01:31

nothing in shadow-cljs yet, want to sort out the API first

thheller18:01:15

can’t really call this cljs.i18n without some sort of approval that this is ok since I consider cljs. sort of reserved

tony.kay18:01:22

So, I guess the options are: - Have a tr with the optional vector notation for context - Have trc to supply context - Make the macro error check and disallow variables…actually the current tr does that, since it has to be a literal string or we can’t extract it. There is a tr-unsafe variant that is unchecked…because sometimes you do need to use a variable for the string.

thheller18:01:30

could use a map instead of the vector too

thheller18:01:57

can add a tr-unsafe fn to the cljs.i18n ns that just delegates to the ITranslate protocol as is

tony.kay18:01:29

yeah…it’s just sanity checking at compile time

thheller18:01:17

but thinking about it .. no matter what the :cljs.i18n/context is better than the vector notation

thheller18:01:26

(tr msgid {:cljs.i18n/context "optional context" ...other params...})

thheller18:01:32

(tr msgid :cljs.i18n/context "optional context" ...other params...)

thheller18:01:36

works both ways

tony.kay18:01:07

Just throwing this out there: ` (tr “message”) (tr “context” “message”) (tr “message {a}” {:a 1}) (tr “context” “message {a}” {:a 1})

tony.kay18:01:14

` why use a vector or map

thheller18:01:39

I don’t particular like the extra string for context

tony.kay18:01:39

they have to be literal strings, so they are easy to detect and parse

thheller18:01:54

to me it feels like I always want the string first, then the context?

thheller18:01:11

but yeah easy to detect

tony.kay18:01:24

perhaps the keyword is better though…it is extensible

tony.kay18:01:49

APIs are such a pain to get right 😉

thheller18:01:11

yeah. I kinda feel like the “wrapped” map argument may encourage too much dynamisn

thheller18:01:17

and we need this info to be static

thheller18:01:51

(let [args {:foo "bar"}] (tr "translate this {foo}" args)) doesn’t work?

tony.kay18:01:02

Yeah, I understand the problem wit macros….I still lean towards the separate macro name for context

tony.kay18:01:18

oh, that does work

tony.kay18:01:25

(your example)…the args pass through

thheller18:01:28

well we dont NEED the args to be static but it feels more explicit and automatically error checks?

tony.kay18:01:44

in fact, the args need to be dyanmic

tony.kay18:01:48

for formatted stuff

thheller18:01:17

the values need to be dynamic? the keys don’t?

tony.kay18:01:47

in formatted stuff, allowing a dynamic map to fill in params is a requirement of the API

tony.kay18:01:07

well, pretty for-sure 🙂

tony.kay18:01:26

facilitates writing things compositionally

thheller18:01:01

it would be more convenient yes but for error-checking reasons static sounds more reasonable

thheller18:01:12

composition goes out the window anyways since this is a macro 😉

tony.kay18:01:20

yeah, but an error means what? It doesn’t format correctly…I think they’ll see that

thheller18:01:27

I mean thing like (tr "hello {name}" :nane username) which could check if the map contains all the required keys

tony.kay18:01:32

(defn formatted-user-info [args]
   (str (tr "..." args) (when (some-cond? args) (tr "..." args)))

tony.kay18:01:33

kind of things

thheller18:01:01

typo detection basically

tony.kay18:01:04

I understand the error checking…and I don’t care about that error checking because it breaks the more interesting and useful cases I do care about

tony.kay18:01:26

if the message doesn’t format correctly, they see that in the output…no compile check needed

tony.kay18:01:51

If they fail to use a literal string, then extraction fails…and that would be hard to catch without compiler help…so I do care about that one

tony.kay18:01:13

it’s about which errors matter

thheller18:01:22

(defn formatted-user-info [{:keys [name condition suffix] :as args}]
  (str (tr "..." :name name ) (when (some-cond? condition) (tr "..." :suffix suffix)))

thheller18:01:39

more to type yes but easier to verify 🙂

tony.kay18:01:53

but are you going to parse the format string?

tony.kay18:01:05

and support the evolving FormatJS format string ICU format?

thheller18:01:08

done at compile time, so why not?

tony.kay18:01:12

including plurals

tony.kay18:01:22

and that also kills pluggable i18n libraries

tony.kay18:01:40

I feel like Edna from The Incredibles…“No Capes!”

tony.kay18:01:18

I think it adds a lot of complexity, a little benefit

thheller18:01:33

I guess thats true

tony.kay18:01:39

and I like the fact that the philosophy of maps in clojure is “I can carry extra stuff and things shouldn’t care”

tony.kay18:01:10

so, if I have a “user” defrecord and want to use it as args, why shouldn’t I?

thheller18:01:21

(defn formatted-user-info [args]
  (str (tr "... {some-key}..." args) (when (some-cond? args) (tr "... {other-key} ..." args)))

thheller18:01:31

also kinda captures what args is expected to contain

tony.kay18:01:47

it does, and FormatJS et al will check that

thheller18:01:50

> if I have a “user” defrecord and want to use it as args, why shouldn’t I?

thheller18:01:12

yeah, having to type that out again would definitely suck

tony.kay18:01:28

although not sure a defrecord is going to work 😜

tony.kay18:01:38

do those convert to js properly?

tony.kay18:01:11

so, back to context….metadata?

tony.kay18:01:27

nah…that’s only boolean convenient

thheller18:01:53

could always treat the last arg as a map on uneven arg count

thheller18:01:11

(tr "..." :cljs.i18n/context "foo" args)

tony.kay18:01:36

I really prefer if there was just a trc

thheller18:01:42

(tr "..." :cljs.i18n/context "foo" {:key value})

tony.kay18:01:56

it’s the shorted thing to type, is trivial to resolve, easy to read

thheller18:01:01

(tr "..." :cljs.i18n/context "foo" :key some-value)

thheller18:01:10

but not extensible?

thheller18:01:00

well trc could also allow a map as context maybe? (trc {} "..." ...)

thheller18:01:18

not sure, something bothers me about having the context first

tony.kay18:01:40

ok, so what if we allow zero-or-more k-v pairs to give extensible options?

tony.kay18:01:48

then trc et al are just wrappers

thheller18:01:12

too bad we can’t have metadata on strings 😞

tony.kay18:01:14

(tr msgid k-v-pairs map-of-args)

tony.kay18:01:20

yeah, I thought that too

tony.kay18:01:27

no named params for args

tony.kay18:01:51

trf could be a wrapper that allows args as named params

tony.kay18:01:03

thus, the core API is just tr…everything else is optional wrapper

thheller18:01:18

the macro doesn’t get much more complicated when we allow kvpairs instead of a map

tony.kay18:01:35

hard to detect which are options and which are args

thheller18:01:36

so not a fan of an extra trf

thheller18:01:50

nah, uneven args the last one is expected to be a map

tony.kay18:01:17

oh, and just roll context et al into args since you don’t know for sure where the boundary is? I guess that’s ok 🙂

tony.kay18:01:36

not suggesting trf is in the core lib…but Fulcro (and other consumers) could provide it

thheller18:01:49

yeah the fulcro api doesn’t need to change at all

thheller18:01:03

just emit calls to the cljs.i18n instead of doing anything itself

tony.kay18:01:30

I was thinking through both user API and implementation…co-mingling…separating them back out now

thheller18:01:40

will need a proof of concept impl anyways and fulcro pretty much already has everything in place

thheller19:01:36

the only point of the cljs.i18n API is pretty much to have something that build tools can access later

thheller19:01:17

its fine if libs wrap it

tony.kay19:01:29

OK, I’m in 🙂

thheller19:01:05

ok, I’ll update the code/readme

thheller19:01:18

and start the impl for shadow-cljs

tony.kay19:01:20

let me know what I can do

tony.kay19:01:48

I can take a first draft at making Fulcro’s lein template support shadow-cljs

thheller19:01:07

right, I wanted to look into that as well 😛

tony.kay19:01:37

if you wanted to give me any quick tips, I’m glad to refine/test it

thheller19:01:46

shadow-cljs currently doesn’t allow a custom cljs.user, thats one things I saw in the template

tony.kay19:01:15

but you do have an after hot load…it’s mainly used to re-call mount

thheller19:01:56

yes :devtools {:before-load ... :after-load ...} both taking fully qualified symbols

thheller19:01:15

:after-load would be figwheels :on-jsreload or whatever its called

tony.kay19:01:50

so, to separate code for “just dev” you just make sure not to require it from prod code, right?

thheller19:01:16

“dev” code usually is loaded via the :preloads option

thheller19:01:24

so the cljs.user namespace you have currently would be a preload

tony.kay19:01:37

nothing forbidden about the name?

tony.kay19:01:03

i.e. it would be a preload…but does the ns need to be something else?

thheller19:01:26

I pretty much always encourage this pattern

tony.kay19:01:53

ok, I’ll start with that

thheller19:01:25

init is called from the HTML (once)

thheller19:01:30

hot reload calls stop, then start

thheller19:01:39

same deal for production

thheller19:01:51

since no code ever calls stop it will be removed

thheller19:01:20

if everything is set up properly no dev code will be left alive

tony.kay19:01:18

Dynamic module loading…same loader API from main cljs?

tony.kay19:01:55

I use the loader for dynamic routing and locale loading

thheller19:01:06

yeah cljs.loader is not great IMHO. it completely does not work with :module-hash-names which hashes output files for caching purposed

thheller19:01:21

so instead of a main.js you get main.<some-hash>.js

thheller19:01:32

since the cljs.loader does things on compile that doesn’t work

tony.kay19:01:44

I’m not in love with it either, but does it work without the hashed names?

thheller19:01:45

can’t know the md5 before finishing compilation

thheller19:01:01

I added rough support for cljs.loader so if you use that it should just work

thheller19:01:05

just ignore :module-loader

thheller19:01:45

:module-loader existed about a year before cljs.loader so it isn’t built on top of it

thheller19:01:14

not sure if I can rework it to just use that due to the ^:const injection stuff. makes it really icky to use

thheller19:01:42

also not a fan of the manual cljs.loader/set-loaded! calls

thheller19:01:00

and requirement that the “entry” namespaces requires cljs.loader

tony.kay19:01:10

um…there was something about the non-manual set-loaded! they tried that didn’t work. It bit me in particular

thheller19:01:12

all of that is handled transpartenly by shadow.loader

thheller19:01:58

I know it was broken the way it was done for cljs.loader yeah

thheller19:01:14

but not aware of any issues for shadow.loader

thheller19:01:28

doubt there are many users though

tony.kay19:01:39

cool. well, it probably would not be hard to support shadow’s through dynamic resolution

thheller19:01:40

(of either I guess)

thheller19:01:16

it would be better if cljs.loader just provided the API and didn’t enforce an implementation as well 😞

tony.kay19:01:36

yeah, that seems less than optimal

thheller19:01:08

anyways, just stick with cljs.loader and it should work as in CLJS

tony.kay19:01:37

ok. Thanks for the tips. I’ll let you know how it goes. The dynamic module loading is a core part of dynamic routing for code splitting and i18n locales

thheller21:01:06

thinking about it some more it might be practical to just create a spec for the analyzer data

thheller21:01:23

and let macros put it there however they want

tony.kay21:01:47

Sure. Sounds reasonable. since you’re still around…trying to run CI tests from command line. Seems that is TBD?

thheller21:01:51

running the tests is TBD yes. generating you can do via the :karma target

tony.kay21:01:14

oh, and then run a karma config on the output?

tony.kay21:01:23

I’ll give that a shot

thheller21:01:52

only did very basic work on that but I think @mitchelkuijpers is using it

tony.kay21:01:18

it’s really just for CI…so anything that makes them run works for me 🙂

thheller21:01:24

basically it just outputs a single file that karma understands

tony.kay21:01:59

more i18n fun, evidently. I got the stuff to compile with the stuff you and Mitchel had talked about with the intl-messageformat, but when I try the tests it dies on this line of generated js:

shadow.js.shim.module$intl_messageformat = require("intl-messageformat");
saying require is not found

thheller21:01:08

whats your config?

tony.kay21:01:20

:ci-tests {:target :karma :output-to “target/ci.js” :ns-regexp “^boo\\..*-spec$” :modules {:main {:entries [boo.CI-runner]}}}

thheller21:01:09

:modules you don’t need, the runner is also auto generated

thheller21:01:28

can set :runner-ns boo.CI-runner if you want though

tony.kay21:01:41

good to know…trying it with just regex

thheller21:01:43

not sure why its emitting require

tony.kay21:01:57

well, that ns would have pulled in intl stuff

tony.kay21:01:31

same problem after a clean build

thheller21:01:27

hmm try settings :js-options {:js-provider :shadow}

thheller21:01:39

not sure why its picking require, really shouldn’t

tony.kay21:01:48

just FYI, that code is generated when compiling i18n.cljc from Fulcro

thheller21:01:55

doesn’t matter

tony.kay21:01:12

js-options goes at the same level as target?

thheller22:01:08

covers what :js-provider means, you are on :require which is only supposed to be used for node builds

tony.kay22:01:38

that fixed it

tony.kay22:01:50

you want me to make a commit of this little project so you can diagnose?

thheller22:01:54

no, I just forgot setting it

tony.kay22:01:04

ah, easy fix then 🙂

tony.kay22:01:24

I’ve got most of it working…the CI thing has been the only hard part so far

thheller22:01:58

maybe commit what you have so I can look over it and make suggestions

tony.kay22:01:12

need to make karma auto-exit with a status code still…

thheller22:01:31

the default runner does that

thheller22:01:57

you really do not need the boo.CI-runner

tony.kay22:01:05

I thought I remved it

tony.kay22:01:28

oh right…the file

thheller22:01:30

(enable-console-print!) is also never required anywhere

thheller22:01:37

shadow-cljs injects that once in the proper place

thheller22:01:43

the :karma finds all namespaces that matches your regexp and makes sure it is loaded before the :runner-ns

thheller22:01:20

so no manual upkeep with those tests-to-run files, although you can of course still do it manually if you prefer

tony.kay22:01:33

I still need to require them for the spec main I think

tony.kay22:01:40

for live test running of Fulcro Spec

thheller22:01:27

shouldn’t need it no

tony.kay22:01:35

During development hot code reload is used to trigger test re-render, and all the tests have to be present in the browser or it won’t find them

tony.kay22:01:44

Fulcro Spec

thheller22:01:14

right .. but … I “hack” into cljs.test and register all tests so they are available at runtime

thheller22:01:39

so you do not need to damn macro to know which tests exist

tony.kay22:01:13

so what should that build look like then? I have to point it at something

thheller22:01:19

but yeah if you stick to the default cljs.test/run-all-tests that doesn’t buy you anything

tony.kay22:01:15

with a :browser target it doesn’t know to scan for tests, and without the module thing it wouldn’t run the spec rendering trigger

thheller22:01:33

:browser-test is meant to that

tony.kay22:01:33

I missed that…that should work

thheller22:01:38

so you could create a :runner-ns fulcro.shadow-test-runner or so

thheller22:01:11

thats also re-usable and doesn’t need to be in the users project

thheller22:01:18

since it doesn’t rely on a macro call

thheller22:01:23

the shadow.test is basically a macro-less copy of cljs.test

tony.kay22:01:05

Unfortunately Fulcro Spec defines it’s own thing internally

thheller22:01:24

right .. you don’t have to use shadow.test (or cljs.test)

thheller22:01:53

the point is that the :browser-test target will ensure that all namespaces matching the regexp will be compiled and loaded before the runner

thheller22:01:02

what the runner does is completely up to you

tony.kay22:01:10

Yeah, that’s all I need

tony.kay22:01:50

It was working as I wrote it, but that will be cleaner

thheller22:01:54

if you have everything setup so the tests are registered at runtime you don’t need to go the macro route that cljs.test took

tony.kay22:01:36

The extra compiler magic of scanning/loading is a nice additional touch

thheller22:01:08

there is probably a whole lot more build tools could provide if properly enabled to do so

tony.kay22:01:58

:test     {:target     :browser-test
                   :output-dir "resources/public/tests"
                   :asset-path "/tests"
                   :devtools   {:after-load boo.client-test-main/start
                                :before-load boo.client-test-main/stop
                                :preloads   [devtools.preload]
                                :http-root  "resources/public"
                                :http-port  8021}}

That look right?

tony.kay22:01:13

oh…output-to

thheller22:01:47

just set :test-dir

thheller22:01:37

the rest should be inferred

thheller22:01:20

unfortunately :http-root currently has to be static part of the configuration so you still need to repeat that

thheller22:01:24

ideally that would be inferred as well

thheller22:01:13

also set :runner-ns

thheller22:01:45

that will automatically set :after-load <runner-ns>/start (and stop)

tony.kay22:01:48

so I need to serve an HTML file somewhere in here

thheller22:01:01

it generates one currently

tony.kay22:01:03

Spec needs a div to mount onto

tony.kay22:01:43

I’m beginning to think what I had was better in some ways…I just want the scanning. The rest of the magic is distracting

thheller22:01:19

you can create the :test-dir/index.html manually

tony.kay22:01:30

let me try that…

thheller22:01:10

thats the default that gets generated otherwise

thheller22:01:16

but yeah the test stuff is pretty rough

thheller22:01:23

open to any kind of suggestions

thheller22:01:51

I’m convinced that we can probably get a testing setup without any configuration at all

thheller22:01:57

that just works

thheller22:01:26

eg. shadow-cljs clj-run fulcro.spec.server

tony.kay22:01:01

pretty easy for CI…would add a dep on Fulcro Spec for browser I would think

tony.kay22:01:31

not really…you just generate the code…yeah, that is probably true

thheller22:01:45

the hard part is running the tests

thheller22:01:49

generating some code is easy

thheller22:01:02

not sure how much shadow-cljs should help with running them, its a build tool after all

thheller22:01:19

but in case of :browser-test we can get close enough to something usable

thheller22:01:45

with some “convention over configuration” we can remove most config config options

tony.kay22:01:07

well, at least for Fulcro Spec it was built around “it works if you have hot code reload”…no other support was assumed, because there wasn’t any 🙂

thheller22:01:06

yeah but you also generate a whole bunch of files in the template that may confuse users

thheller22:01:40

I prefer generating as little files as possible. also less likely for updates to break stuff just because a generated file is now outdated

thheller22:01:05

so if the build tool can offload some of the generation that can be very useful

tony.kay22:01:09

:test     {:target    :browser-test
                   :test-dir  "resources/public/test"
                   :ns-regexp "^boo\\..*-spec$"
                   :runner-ns boo.client-test-main
                   :devtools  {:http-port 8021
                               :preloads  [devtools.preload]
                               :http-root "out/demo-test-dummy"}}
is what I have now…but it does not find my index.html when I try to load

thheller22:01:51

:preloads [devtools.preload] is no longer required as of [email protected]. it is automatically added if cljs-devtools is on the classpath

tony.kay22:01:52

http-root 😕

thheller22:01:04

right hehe the directory

thheller22:01:09

:ns-regexp "-spec$" is also safe to do since it will only include matching files, eg. nothing in .jar files

thheller22:01:35

who wants to run other peoples tests 😉

thheller22:01:13

but looks good otherwise

thheller22:01:36

/js/test.js is the generated file in case you are using a custom index.html

tony.kay22:01:10

yeah…working on that now. It’s up, just going to check the hot reload

tony.kay22:01:14

I need to push spec’s css into component-local css. I wrote the very early draft of spec, but someone else wrote the bulk of it…it needs some work…

thheller22:01:25

the :cards build may also benefit from the :browser-test treatment?

tony.kay22:01:45

auto-scanning for devcards…yeah

thheller22:01:23

I don’t really recommend running via lein but its ok I guess

thheller22:01:38

still need to add that tools.deps support

tony.kay22:01:53

well, I need the server support stuff in project.clj, and Cursive…

tony.kay22:01:01

don’t want to manage two deps lists

tony.kay22:01:07

(three, really, with npm)

thheller22:01:08

yeah understandable

thheller22:01:09

you can :lein {:profile "+cljs"} and create a dedicated :cljs profile in project.clj if desirable

thheller22:01:35

technically shadow-cljs should just be a dev dependency

tony.kay22:01:43

yeah, I haven’t (obviously) finished with the project file

tony.kay22:01:52

still have all the cljs builds defined

thheller22:01:45

just wanted to mention the option of :lein :profile 😉

tony.kay23:01:38

yeah, I’ll probably add that. ANy clue why Karma won’t exit, and then disconnects? I’m calling the done from stop

tony.kay23:01:10

ah, no…that is all your code

tony.kay23:01:17

perhaps I’m missing something

thheller23:01:50

hmm I though karma always keeps running?

tony.kay23:01:03

for CI it needs to exit with a status code

tony.kay23:01:14

when I was using doo it managed it, so I don’t know

tony.kay23:01:39

Ah…I have a very old version of the karma stuff

thheller23:01:23

I never went beyond running karma start which re-runs tests on file change so it isn’t supposed to exit

tony.kay23:01:09

singleRun is supposed to exit so that you can use it with things like Travis and CircleCI

thheller23:01:35

npx karma start --single-run
11 01 2018 00:07:03.055:INFO [karma]: Karma v2.0.0 server started at 
11 01 2018 00:07:03.058:INFO [launcher]: Launching browser ChromeHeadless with unlimited concurrency
11 01 2018 00:07:03.063:INFO [launcher]: Starting browser ChromeHeadless
11 01 2018 00:07:03.314:INFO [HeadlessChrome 0.0.0 (Mac OS X 10.12.6)]: Connected on socket c0LoCJjPKzBp3pRIAAAA with id 16697457
LOG: 'Testing shadow.inspect-test'
LOG: '{:type :kv, :type-desc "cljs.core/PersistentArrayMap", :count 1}
'
LOG: '{:type :coll, :type-desc "cljs.core/PersistentHashSet"}
'
LOG: 'Testing demo.app-test'
LOG: 'once before'
LOG: 'each before'
HeadlessChrome 0.0.0 (Mac OS X 10.12.6) demo.app-test a-failing-test FAILED
	FAIL in   (a-failing-test) (at http:60704:85)
	expected: (=
	            1
	            2)
	  actual: (=
	            1
	            2)
	    diff: - 1
	          + 2

LOG: 'each after'
LOG: 'each before'
LOG: 'each after'
LOG: 'once after'
LOG: '
Ran 3 tests containing 1 assertions.'
LOG: '1 failures, 0 errors.'
HeadlessChrome 0.0.0 (Mac OS X 10.12.6): Executed 3 of 3 (1 FAILED) (0 secs / 0.011 secs)
HeadlessChrome 0.0.0 (Mac OS X 10.12.6) ERROR
  Disconnected, because no message in 10000 ms.
HeadlessChrome 0.0.0 (Mac OS X 10.12.6): Executed 3 of 3 (1 FAILED) DISCONNECTED (10.03 secs / 0.011 secs)

thheller23:01:49

guess I’m supposed to call something

thheller23:01:05

it does exit with 1 though

tony.kay23:01:19

right, but it also does so when they pass 😉

tony.kay23:01:25

because of the disconnect

thheller23:01:29

ah hehe makes sense

thheller23:01:38

let me check what I’m supposed to be calling

tony.kay23:01:46

I’m going to try to upgrade my deps

tony.kay23:01:26

yeah, single-run just isn’t working

thheller23:01:44

k I think I found it

thheller23:01:32

my brain seems to now work anymore

thheller23:01:48

(prn :calling-end-run-tests)
                (ct/report {:type :end-run-tests})
                (prn :done-end-run-tests)

thheller23:01:00

(defmethod ct/report [::karma :end-run-tests] [_]
  (prn :in-end-run-tests)
  (js/__karma__.complete #js {"coverage" (aget js/window "__coverage__")}))

thheller23:01:10

(prn :in-end-run-tests) is never printed

thheller23:01:16

the other two are

thheller23:01:21

mystery to me why

tony.kay23:01:13

wrong multimethod dispatch key?

tony.kay23:01:24

::karma getting the right ns?

thheller23:01:28

the env seems to be cleared prematurely

tony.kay23:01:10

I’ll try it out

tony.kay23:01:21

cooking some food…sorry for the slowness