Fork me on GitHub
#shadow-cljs
<
2018-08-22
>
chrisetheridge11:08:26

@thheller do you have any plans to support requring CSS in JS, like webpack allows? what do you use for this functionality?

thheller11:08:32

I do have plans for that yes, nothing actually usuable yet though. I just use node-sass currently.

urbanslug12:08:01

So after realizing that the browser test wouldn't do for me I'm exploring node-test

urbanslug12:08:28

I think this is what react uses with jest when you create a react app from the scaffold

urbanslug12:08:39

basically testing even my node modules

urbanslug12:08:11

seems there isn't much literature about this

urbanslug12:08:52

========= Running Tests =======================
SHADOW import error /home/user/project/.shadow-cljs/builds/test/dev/out/cljs-runtime/shadow.js.shim.module$semantic_ui_react$dist$es$index.js
/home/user/project/node_modules/semantic-ui-react/dist/es/index.js:2
import _Confirm from './addons/Confirm';
       ^^^^^^^^

SyntaxError: Unexpected identifier
    at new Script (vm.js:74:7)
    at createScript (vm.js:246:10)
    at Object.runInThisContext (vm.js:298:10)
    at Module._compile (internal/modules/cjs/loader.js:657:28)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)
    at Module.load (internal/modules/cjs/loader.js:599:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
    at Function.Module._load (internal/modules/cjs/loader.js:530:3)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:20:18)

thheller14:08:13

@urbanslug thats ES6 code which doesn't work natively in node. there is some option to enable it but I forgot.

thheller14:08:36

you are also probably testing browser stuff so :browser-test or :karma may be better suited

urbanslug15:08:32

@thheller I want it to work on CI

thheller15:08:48

:karma then

urbanslug15:08:49

maybe a headless browser in a docker container idk

urbanslug15:08:56

ok let me check out karma

urbanslug15:08:02

it seemed to only talk about angular

urbanslug15:08:10

and I'm doing react

urbanslug15:08:17

Which linter do you use?

thheller15:08:40

karma is generic, not tied to any framework. its just a headless browser basically.

thheller15:08:42

I don't use a linter

urbanslug15:08:19

Ah > karma is generic, not tied to any framework. its just a headless browser basically.

urbanslug16:08:23

hmm I have a problem with this args: ["shadow.test.karma.init"], in my karma.conf.js

urbanslug16:08:30

seems to be an arg to karma-run

urbanslug16:08:02

I'm basically having it be app.core-test

urbanslug16:08:53

Uncaught ReferenceError: app is not defined...

thheller16:08:35

no thats wrong

thheller16:08:47

you leave it as is

thheller16:08:53

that is the main test runner

thheller16:08:17

this works. no need to adjust anything

thheller16:08:00

like all test targets your tests are included via the :ns-regexp

thheller16:08:19

ALL included tests are then executed by shadow.test.karma/init

thheller16:08:10

basically that just makes sure that some output is emitted that karma can understand

thheller16:08:34

unless you write your own runner ns you do not touch args

urbanslug16:08:30

same thing though Uncaught ReferenceError: shadow is not defined...

thheller16:08:51

that probably means that your paths are wrong

thheller16:08:25

check that basePath: 'out/demo-karma' and files match your paths

urbanslug16:08:31

tree is like so

├── src
├── target
├── test

thheller16:08:11

:output-to "target/ci.js"

urbanslug16:08:17

I'm using your basepath target

thheller16:08:21

what is your :output-to?

thheller16:08:29

basePath: 'target',
        // The file itself
        files: ['ci.js'],

urbanslug16:08:43

Ok I know where I messed up

thheller16:08:47

basically the two combined must match whatever :output-to is

urbanslug16:08:04

I had ::output-to "target/cli.js"

urbanslug16:08:11

cli instead of ci

thheller16:08:37

I don't use karma myself so its a wonder any of this works at all

thheller16:08:47

docs could certainly be improved

urbanslug16:08:50

Do you test your code?

thheller16:08:02

some of it yes

thheller16:08:18

in clojure though

urbanslug16:08:20

ha! the test ran successfully

urbanslug16:08:30

and without chromium

urbanslug16:08:42

how? > in clojure though

urbanslug16:08:48

I mean with chromium not chrome

thheller16:08:59

lein test 😉

urbanslug16:08:16

I don't have lein on my system 😄

thheller16:08:22

I should write more tests but meh testing 😉

urbanslug16:08:46

True! Tests are hell and nobody appreciates the effort that goes into them

urbanslug16:08:50

which sometimes is a ton

thheller16:08:07

yep its often more code to write the test than the actual code

thheller16:08:13

especially UI testing

thheller16:08:18

thats why I don't do it

thheller16:08:30

basically I only test critical functions that work with pure data

urbanslug16:08:53

I also installed what was here https://github.com/Day8/re-frame-test#running-the-cljs-tests-with-karma but not sure that it helped

urbanslug16:08:21

this is my aim too but I literally needed a way to run the tests somehow in CI > basically I only test critical functions that work with pure data

urbanslug16:08:29

and I didn't have one

urbanslug16:08:39

is there a reason you chose a different dir for your karma tests output? than the usual resources/public...

urbanslug16:08:44

When I figure out what I'm doing I'll try improve the docs. They could do with some clarification. Comments like don't mess with karma client args

urbanslug16:08:52

Also the need to set CHROME_BIN=chromium or whatever it is I wonder how nicely this will play in CI

urbanslug16:08:28

slow tests are tests that people will refuse to run :thinking_face:

thheller16:08:47

I can't make any recommendations regarding karma. I don't use it. I don't know how it works.

thheller16:08:10

even less so in a CI env

urbanslug16:08:55

well I'll let you know what I learn anyway

urbanslug16:08:03

when I learn it...

heyarne16:08:10

could it be that hot-reloading multimethods doesn't work as expected?

thheller16:08:12

depends on what you expect?

heyarne16:08:09

probably true. it didn't seem to execute the updated code when i changed the source of the dispatch function

heyarne16:08:20

until i Ctrl + C'd and restarted

heyarne16:08:29

and i expected it to execute it

heyarne16:08:39

without having to restart the build

thheller16:08:22

ah yeah defmulti is basically defonce. you can only change the dispatch fn if its a reference to some other fn

thheller16:08:40

(defmulti foo bar) works but (defmulti foo (fn [x] ...)) doesn't

heyarne16:08:55

hm... i had it as a reference

richiardiandrea18:08:20

has anybody have this before with deps.edn?

shadow-cljs - starting via "clojure"
Error building classpath. nil
java.lang.NullPointerException

richiardiandrea18:08:01

now I got it, crazy maps 😄

richiardiandrea18:08:13

it's a clojure issue

richiardiandrea18:08:37

error reporting is not helpful when there are mistakes in the deps.edn file

chrisetheridge18:08:34

@urbanslug @thheller we currently have Karma running tests under shadow-cljs in a CI env. happy to help if you need it

richiardiandrea18:08:23

are folks here using shadow-cljs in Cursive? I have a question 😄

richiardiandrea18:08:07

@thheller how do you setup the REPL? If the port is random, can you still use the nrepl file automagically for that?

richiardiandrea18:08:40

(writing a post btw, so this will all be documented :D)

thheller18:08:17

using .nrepl-port in non-lein projects

richiardiandrea18:08:54

uhm, which Run configuration do you select?

thheller18:08:15

clojure repl -> remote -> use leiningen port

richiardiandrea18:08:31

and how do you lauch the nrepl server? within Cursive?

thheller18:08:10

always in the terminal

thheller18:08:04

just running npx shadow-cljs server in the build-in terminal and leaving that running

richiardiandrea18:08:34

ok I though there was a way to run it inside, if external then I am already good 😄

urbanslug18:08:35

@biscuitpants hmmm do you have a way to watch your karma tests?

richiardiandrea19:08:01

@thheller question, is there a function for unwatching a build?

richiardiandrea19:08:08

I see shadow/stop-worker

richiardiandrea19:08:25

but start-worker is priivate

thheller19:08:33

watch starts the worker

richiardiandrea19:08:07

ok, what about making it consistent? adding unwatch or something? even just an alias

thheller19:08:28

unwatch isn't exactly clear what it means

thheller19:08:40

could just mean stop getting log messages but leave worker running

richiardiandrea19:08:20

will think about it more, don't even know if there is some usability issue there, just going through what I have written it felt ....itchy 😄

thheller19:08:23

I think its fine. just need to document what a worker is since people technically only ever see watch

thheller19:08:12

but is a (shadow/watch :the-build {:autobuild false}) still a watch? 😉

richiardiandrea19:08:55

well, I was thinking if there is a use case where you don't want to watch the logging

richiardiandrea19:08:52

because logging gives you the errors

thheller19:08:53

well thats just compile which doesn't start a worker 😉

thheller19:08:33

worker is just more generic term for "process responsible for managing the build compilation"

thheller19:08:53

watching anything is actually optional

richiardiandrea19:08:08

yeah...if we had protocol server on the shadow server, one wouldn't need to check the terminal for errors I guess, but we are not there yet

richiardiandrea19:08:28

so you actually have to watch

thheller19:08:20

we'll the pure REPLs (node-repl, browser-repl) don't watch at all so it is possible working without watch

thheller19:08:53

just need to manually load stuff which is totally fine too

richiardiandrea19:08:05

yep for browser you actually see errors in there

richiardiandrea19:08:15

true, for now node, you will see evaluatiion errors

richiardiandrea19:08:27

I like this actually, I think I will try this workflow

thheller19:08:38

I also added shadow/watch-compile-all! for compile-on-key-press vs compile-on-file-save

richiardiandrea19:08:06

that is very cool actually

richiardiandrea19:08:18

fits very well into my workflow

thheller19:08:40

forgot who I added it for but it makes total sense

thheller19:08:45

watch without autobuild

thheller19:08:12

and bind the trigger to a key. so you can compile all changed files when pressing that key instead of all the time a file is changed

thheller19:08:56

watch often is a bit over eager

richiardiandrea19:08:18

that key just send a REPL command?

richiardiandrea19:08:25

yep I guess 😄

richiardiandrea19:08:50

oh the above command, right

thheller19:08:55

yeah just send (shadow.cljs.devtools.api/watch-compile-all!) to the REPL on keypress

thheller19:08:01

simple setup with REPL commands in cursive

thheller19:08:01

but yeah I really like the run in terminal + remote REPL connect in cursive

thheller19:08:23

when I get tired of nrepl I sometimes use clojure.main REPL with -m shadow.cursive-repl

thheller19:08:30

that autoconnects to the socket repl instead of nrepl

richiardiandrea19:08:51

I was trying just now clojure -A:dev:tree -m shadow.cljs.devtools.cli server

thheller19:08:12

how you start the server doesn't really matter

thheller19:08:28

can be embedded too

richiardiandrea19:08:05

yeah I am documenting both..for nrepl this is also valid clojure -A:dev:test -m nrepl.cmdline (does not end up in shadow.user though

richiardiandrea19:08:06

and the you need also --middleware I guess, so I am not documenting that one 😄

richiardiandrea19:08:11

how do you connect to socket REPL?

richiardiandrea19:08:18

does not seem to work here

thheller19:08:19

nrepl is horrible to setup manually

richiardiandrea19:08:35

Exception starting REPL: java.lang.ArithmeticException: integer overflow

thheller19:08:38

clj -m shadow.cursive-repl should just work (+ whatever aliases you need of course)

richiardiandrea19:08:03

ok will try that

thheller19:08:33

still haven't played with the cursive deps.edn support. not on EAP at the moment.

richiardiandrea19:08:59

kk yeah well, I don't see much here actually

richiardiandrea19:08:10

@thheller is there a difference between repl and nrepl-select?

thheller19:08:48

repl delegates to nrepl-select when connected via nrepl.

thheller19:08:17

nrepl-select just skips the check if you are in nrepl if you know you are in nrepl

thheller19:08:08

I recommend using repl since it also works for socket repl and just looks better 😉

richiardiandrea21:08:02

@thheller so watch-compile-all! does not work if I am not watching?

richiardiandrea21:08:21

because I want a worker and do not want to watch

richiardiandrea21:08:31

but want watch-compile-all! 😄

thheller21:08:09

yeah it still needs the worker. its meant to be combined with (shadow/watch :the-build {:autobuild false}) for now

thheller21:08:36

you do want to watch though since it otherwise wouldn't pickup file changes

richiardiandrea21:08:38

oh so in that case wouldn't start-worker make sense?

thheller21:08:43

so triggering a compile wouldn't do anything

thheller21:08:53

just look at the impl of watch

thheller21:08:26

it also hooks up the output printing and such

thheller21:08:26

I guess you could argue that naming of all of this isn't great

thheller21:08:37

but I suck at naming and couldn't come up with something useful

richiardiandrea21:08:53

yeah I think that is my main objection

thheller21:08:55

watch-compile-all! is also meant for force-triggering a compilation for builds that may be stuck

richiardiandrea21:08:02

yep I think I got it now

thheller21:08:12

say a missing npm dep currently leaves the build stuck

richiardiandrea21:08:16

just was missing (shadow/watch :script {:autobuild false})