Fork me on GitHub
#clojurescript
<
2016-04-04
>
urbanslug14:04:50

Hey, I can’t really figure this out. Is https://github.com/cemerick/clojurescript.test (which is deprecated) the one that is being referred to here https://github.com/clojure/clojurescript/wiki/Testing ?

urbanslug14:04:29

@anmonteiro: So users should migrate their tests to doo?

urbanslug14:04:40

This is going to hurt.

anmonteiro14:04:59

sorry where is Doo mentioned in the links you pasted?

mfikes14:04:20

You don’t need to use Doo to write ClojureScript tests with cljs.test simple_smile

urbanslug14:04:52

"I strongly suggest migrating to use the official core cljs.test + https://github.com/bensu/doo for test-runners and leiningen/boot integration. Thanks to all contributors for helping make testing ClojureScript workable until those tools arrived/matured!"

anmonteiro14:04:56

no you don't need to use Doo

urbanslug14:04:14

but cljs.test is deprecated?

anmonteiro14:04:20

no, it's not

urbanslug14:04:20

or that readme is wrong?

anmonteiro14:04:40

what's deprecated is that clojurescript.test library

anmonteiro14:04:11

cljs.test is the official one and is not deprecated

pbostrom14:04:20

cemerick/cljs.test -> clojure.core/cljs.test

urbanslug14:04:47

anmonteiro: Then I guess you didn’t quite understand my question.

urbanslug14:04:58

However, I have the answer now.

anmonteiro14:04:20

apologies if I didn't understand

urbanslug14:04:57

The readme needs clarification that cljs.test can be used or doo can be used.

anmonteiro14:04:20

I'm not sure I follow, you can actually use both

anmonteiro14:04:35

cljs.test for writing the tests, and lein-doo for running them

anmonteiro15:04:03

but: you can run the tests without lein-doo simple_smile

anmonteiro15:04:14

hope that clarifies things

urbanslug15:04:44

Oh I see, the readme says "...for test-runners…"

anmonteiro15:04:23

doo for test-runners

anmonteiro15:04:37

I think that by test-runners it means circle, travis, etc

urbanslug15:04:43

Yes it does. I wasn’t reading it right. I got it as migrate from cljs.test to doo

urbanslug15:04:29

but these tests can be run without. Because the tests I have run without doo.

lvh15:04:28

lein-do is a thing that helps you run your tests against a variety of js backends especially browsers

lvh15:04:34

it’s mostly orthogonal to your testing library

lvh15:04:00

I mean, it’s not entirely because doo has to know how to run those tests; but it is in that you don’t strictly need it

maio15:04:22

s/lein-do/lein-doo/

numberq15:04:41

Is there a good way to read a file with CLJS? At the moment I'm using a macro in a .clj file called from my .cljs, which just slurps the file, and that works great - if I pass the macro the string literal of the filepath. I'd like to put that string literal in a def variable, but that's giving me issues because of quoting and unquoting shenanigans in the macro. I'm pretty new to macros, so maybe this is just my own ignorance, but I can't find a way to format the body so (slurp (io/file map-file)) evaluates the (slurp (io/file )) part as Clojure but pulls the map-file variable from ClojureScript.

darwin16:04:13

@numberq: you cannot pull runtime value of map-file from clojurescript, macros are evaluated during cljs compile time, not during cljs run time

darwin16:04:48

the question is what do you want to achieve, is map-file known at cljs compile time?

numberq16:04:05

Yes it is. In cljs, it calls (load-map map-file), where load-map is the macro located in clj, and map-file is a def variable created in cljs

darwin16:04:01

I mean, is *value* of map-file known at cljs compile time? it seems to me that you want to run slurp on a file, whose name is known at cljs run time

numberq16:04:33

Yes the value is known at cljs compile time. That's exactly what I want to do. Is there no way to do that? Or is there some other way to read a local project file with cljs, without using macros?

martinklepsch16:04:39

are there any particular libraries people use to decode JWT tokens?

darwin16:04:06

if the value is known at compile time, why don’t you hard-code it in the macro?

darwin16:04:22

in cljs you would have to use some library function from underlying platform, in browser it is not possible for obvious reasons, under nodejs it would be readFileSync[1] for example, https://nodejs.org/api/fs.html#fs_fs_readfilesync_file_options

numberq16:04:27

Ok, I'll look into that, thanks

numberq16:04:11

Also, the reason I don't want to hardcode it into the macro is because there will at some point be a lot of different maps being loaded, and it would be nice to just build that into a variable

darwin16:04:37

so define those variables on clj side, and call a macro which does the job of calling various (load-map …) calls at compile time, there is no need to do this on cljs side (during runtime) if all is known at compile time

Yehonathan Sharvit16:04:10

Is there a way to use cljs.test in a continuous integration env (e.g circleci, travis-ci)?

Yehonathan Sharvit16:04:32

The problem I encounter is that run-all-tests always returns nil

Yehonathan Sharvit16:04:47

So I have no way to detect if the tests have passed or failed

richiardiandrea16:04:41

or you can also use lein-doo which is a very good testing tool

Yehonathan Sharvit16:04:27

how do I set the exit code of my script?

Yehonathan Sharvit16:04:52

So that phantomjs will exit with an error code?

darwin16:04:54

@viebel: not sure about your setup, this is what I do with phantomjs in my runner script: https://github.com/binaryage/cljs-devtools/blob/master/test/resources/phantom.js#L27

darwin16:04:56

but maybe there is a better way to do that

denik21:04:53

Given a large CLJS (om.next) app, how would I go about splitting out one component for stand-alone use, for example to be embedded in an iframe?

danielpcox21:04:23

Does anyone here have a really good example of using d3 from ClojureScript? I'm having some trouble just googling for one

mvaline21:04:51

I have an example drawing a tree-map in reagent @danielpcox if that helps

mvaline21:04:05

using d3 from cljsjs

danielpcox21:04:23

Sure, I'd be interested. Thanks

isak22:04:12

@denik you'd specify a different build with a different entry point namespace, and use "^:export" for any defns that need to be callable from javascript