Fork me on GitHub
#figwheel-main
<
2018-09-03
>
melodylane01:09:02

anyone here currently using figwheel-main with cider?

melodylane01:09:50

I'm currently getting 'Eval timed out' exceptions whenever I try to use a REPL

dpsutton02:09:58

i just cranked up https://github.com/pesterhazy/cljs-spa-example with CIDER and i was able to get everything going. do you want to chat in #cider

melodylane02:09:56

After doing the obvious thing and updating everything, it seems to be working consistently again 🤞. Thank you though!

👍 4
cider 4
bhauman12:09:22

I’d love some folks to kick the tires on the new testing support in 0.1.9-SNAPSHOT https://figwheel.org/docs/testing.html

bhauman12:09:56

along with the asynchronous main script support

bhauman12:09:14

I’ve been building toward providing an effortless testing setup in figwheel for years, I think that these features deliver a lot of value but I’d love some feedback

pesterhazy12:09:50

will give it a try today

pesterhazy14:09:04

Ok so trying to run -main fn as a cli entry point on my project, running

clj -m figwheel.main -co dev.cljs.edn -m playground.test-runner
I get
2018-09-03 16:00:01.740:INFO::main: Logging initialized @26937ms
but then nothing

pesterhazy14:09:52

If I specify an invalid namespace like playground.test-runner111, it correctly reports an error

pesterhazy14:09:15

But if the ns exists but has no fn called -main, there's no error message

pesterhazy14:09:29

Does this boot up a browser in the background, or node?

bhauman14:09:07

This boots up a browser by default

pesterhazy14:09:20

I guess that's the part that's not working then

bhauman14:09:39

well you need a -main fn

pesterhazy14:09:01

I did try that first of course, with the same result

bhauman14:09:29

so nothing happens and no browser launches

pesterhazy14:09:51

correct (I have two Chromes running already, but nothing happens in those either)

bhauman14:09:21

that is very odd

bhauman14:09:33

and your example is minimal?

pesterhazy14:09:52

Just tried with browsers closed, nothing happens either

pesterhazy14:09:06

I'll try to repro in cljs-spa-example, which is pretty minimal

bhauman14:09:09

that would be helpful

pesterhazy14:09:10

Same problem:

cljs-spa-example$ clj -m figwheel.main -co dev.cljs.edn -m cljs-spa.test-runner
[Figwheel] Validating figwheel-main.edn
[Figwheel] figwheel-main.edn is valid \(ツ)/
[Figwheel] Compiling build dev to "target/public/compiled/app.js"
[Figwheel] Successfully compiled build dev to "target/public/compiled/app.js" in 2.615 seconds.
2018-09-03 16:10:06.345:INFO::main: Logging initialized @10295ms

bhauman14:09:24

that is wild

bhauman14:09:39

do you have :open-url false?

bhauman14:09:34

you have :open-url false

pesterhazy14:09:42

I did not make that connection 🙂

bhauman14:09:36

no worries its an important note

pesterhazy14:09:39

seriously though it wasn't obvious to me that those two were connected

bhauman14:09:14

yeah thats how the env get’s started

bhauman14:09:31

I know that it seems like :open-url is only related to the --build option

bhauman14:09:17

but I think this will all was out in the end because you are going to be using :launch-js to run your tests in headless chrome

bhauman14:09:22

I perhaps should warn users that they have chosen to not automatically launch a JS env

bhauman14:09:15

and thanks for looking at this, this is very helpful

pesterhazy14:09:38

Now I'm trying the run-tests-async macro

pesterhazy14:09:46

I get

Use of undeclared Var figwheel.main.testing/empty-env

bhauman14:09:11

oh dang well thats easy to fix

bhauman14:09:48

that’s a path less travelled thanks for finding it

bhauman14:09:03

@pesterhazy if you add cljs-test-display back it should work

bhauman14:09:12

@pesterhazy I just deployed a fix for that

bhauman14:09:39

dang I never tested it with just one namespace

pesterhazy14:09:49

ok cool, just added cljs-test-display back in, now I get test results

pesterhazy14:09:14

this is what it looks like ^^

pesterhazy14:09:39

it tells me that 2 test failed (good!) but not which of them failed

bhauman14:09:26

yeah its just using the cljs.test test report

bhauman14:09:36

its just cljs test

bhauman14:09:19

you should be able to just run (run-tests-async 5000)

bhauman14:09:26

and it should find your tests

pesterhazy14:09:44

cljs.test test report prints to the console which tests are failing and why - I guess cljs-test-display overrides that

pesterhazy14:09:29

with the latest SNAPSHOT, I removed the cljs-test-display again, now I get better output:

Testing cljs-spa.core-test

FAIL in (arithmetic-test-expected-to-fail) (at http:433:14)
hello
expected: (= 3 (+ 1 5))
  actual: (not (= 3 6))

FAIL in (async-test-exepcted-to-fail-with-timeout) (:)
Promise rejected: Promise failed to resolve in 50ms
expected: false
  actual: false

Ran 2 tests containing 2 assertions.
2 failures, 0 errors.
#error {:message "ClojureScript async test run failed", :data {:type :end-run-tests, :fail 2, :error 0, :pass 0, :test 2}}

bhauman14:09:49

ah that makes sense

pesterhazy14:09:17

might be worth considering reporting to the console as well in cljs-test-display

bhauman14:09:23

and does it work with (run-tests-async 5000)

bhauman14:09:50

@pesterhazy yeah thats something to think about

pesterhazy14:09:52

after the main output I still get a long, basically irrelevant Java stacktrace - it would be cool to hide that for this specific use case

bhauman14:09:09

I thought long and hard about that

bhauman14:09:44

and the problem is that if I hide it you can’t compose over figwheel.main/-main

pesterhazy14:09:15

with just (run-tests-async 5000) all I get is

2018-09-03 16:35:18.642:INFO::main: Logging initialized @8205ms
Opening URL 

Testing cljs-spa.test-runner

Ran 0 tests containing 0 assertions.
0 failures, 0 errors.
:figwheel.main.testing/success
even though I did require the cljs-spa.core-test namespace in the test runner. Looks like it's not auto-detecting the tests

bhauman14:09:18

it is supposed to be top level entry point

bhauman14:09:58

@pesterhazy try cleaning and see if you get the same result

pesterhazy14:09:11

I assume you're using the exception to signal failure (status code not= 0) to the top level?

bhauman14:09:44

If I System.exit its not very friendly

bhauman14:09:35

I could have a top level -main that uses a main that composes

bhauman14:09:02

or that plays well as a library function

bhauman14:09:37

the output looks way better if I System.exit

bhauman14:09:38

its cool that it worked with your promise tests

bhauman14:09:15

Yeah if you clean it should detect the tests

bhauman14:09:16

which of course is kind of a problem

pesterhazy14:09:05

hmm... if I run

rm -rf target target-prod dist && clj -m figwheel.main -co dev.cljs.edn -m cljs-spa.test-runner
, I get exception in the console:
(index):136 Uncaught ReferenceError: goog is not defined
    at (index):136

pesterhazy14:09:34

first error is

(index):126 GET  404 (Not Found)

bhauman14:09:44

sounds racey

bhauman14:09:08

if you just do one and then the other does that happen?

pesterhazy14:09:17

same thing if I reload the browser

bhauman14:09:31

that doesn’t make any sense

bhauman14:09:43

I wonder what’s happening

pesterhazy14:09:47

but if I restart clj - without removing target/ etc - it works

bhauman14:09:07

but if you remove dist

bhauman14:09:20

you need to rebundle right?

bhauman14:09:47

and target prod has nothing to do with this current build

bhauman14:09:06

what if you just remove target/public?

pesterhazy14:09:20

good points, let me try again

pesterhazy14:09:59

ok pushed a change, the scripts scripts/tests accepts a flag --reset now

pesterhazy14:09:17

scripts/tests --reset
gives me
[Figwheel] Validating figwheel-main.edn
[Figwheel] figwheel-main.edn is valid \(ツ)/
[Figwheel] Compiling build dev to "target/public/compiled/app.js"
[Figwheel] Successfully compiled build dev to "target/public/compiled/app.js" in 6.484 seconds.
2018-09-03 16:53:26.402:INFO::main: Logging initialized @13612ms
Opening URL 

pesterhazy14:09:23

and then hangs

pesterhazy14:09:48

in the console,

Failed to load resource: the server responded with a status of 404 (Not Found)
cljs_deps.js:1 Failed to load resource: the server responded with a status of 404 (Not Found)
deps.js:1 Failed to load resource: the server responded with a status of 404 (Not Found)
cljs_deps.js:1 Failed to load resource: the server responded with a status of 404 (Not Found)
deps.js:1 Failed to load resource: the server responded with a status of 404 (Not Found)
cljs_deps.js:1 Failed to load resource: the server responded with a status of 404 (Not Found)
(index):136 ClojureScript could not load :main, did you forget to specify :asset-path?
(anonymous) @ (index):136
(index):136 Uncaught ReferenceError: goog is not defined
    at (index):136
(index):136 Uncaught ReferenceError: goog is not defined
    at (index):136
(index):136 Uncaught ReferenceError: goog is not defined
    at (index):136
(index):136 Uncaught ReferenceError: goog is not defined
    at (index):136
(index):136 Uncaught ReferenceError: goog is not defined
    at (index):136
(index):136 Uncaught ReferenceError: goog is not defined
    at (index):136
(index):136 Uncaught ReferenceError: goog is not defined
    at (index):136

bhauman14:09:50

doesn’t make much sense to me

bhauman14:09:03

its like the asset path isn’t set correctly

bhauman14:09:38

oh that’s only caused when the bundle is removed

bhauman14:09:54

hmmm but the bundle is regenerated

bhauman15:09:03

still sounds racey

bhauman15:09:01

the compiler copies the bundle to your output directory

bhauman15:09:37

if its not there when you start the compile or hasn’t finished flushing that could be a problem

bhauman15:09:10

do you really need to generate the bundle every time you run tests?

bhauman15:09:41

or am I missing something? you are hashing the bundle or something?

bhauman15:09:02

OK I’m somewhat suspect of this as a minimal example, but I’m grateful that we are able to see these behaviors, at the same time I think this particular behavior isn’t related to the code that runs -main.

bhauman15:09:02

failing to detect the tests is a problem that happens when there is only a partial anaylsis of source files

pesterhazy15:09:03

I recreate doublebundle.js on every run, but it's a no-op if the bundle exists and it's up to date, so I think the problem is not related to that

pesterhazy15:09:03

the file that 404s is cljs_deps.js, so I'm wondering why that doesn't exist

bhauman15:09:27

sounds like either a race condition

pesterhazy15:09:30

in fact target/public/cljs-out/dev/goog/deps.js - the file that 404s in the browser .- exists

pesterhazy15:09:38

is it possible that target/ is not on the classpath?

bhauman15:09:12

this is a very strange interaction

bhauman15:09:24

that seems like it only happens when you mess with the bundle

pesterhazy15:09:38

I notice that I don't see the orange "adding target/ to classpath" message that used to pop up after cleaning

pesterhazy15:09:09

why would messing with doublebundle.js cause goog/deps.js not to be found the first time you run it?

bhauman15:09:10

OK that’s it

pesterhazy15:09:37

just tried it, if I remove the foreign-libs stanza from deps.cljs.edn, I get the same problem, so I don't think it's related to doublebundle.js at all

bhauman15:09:55

I don’t think target is getting added when you use main!!

bhauman15:09:12

and there is the problem

bhauman15:09:44

good catch!

bhauman15:09:02

thanks man!!

pesterhazy15:09:30

no, thank you! 🙂

bhauman15:09:58

but how did it work the other times?

pesterhazy15:09:39

the second time around, target/ is already there on startup, and it's in :paths in deps.edn

bhauman15:09:12

second time around?

pesterhazy15:09:36

I mean if I Control-C clj and restart it, it works again

pesterhazy15:09:04

because then the target directory is already there and gets added to the classpath by clj

bhauman15:09:27

but the first time the target has to be created

bhauman15:09:36

before its added to the classpath

pesterhazy15:09:49

... which is too late for it to be noticed by clj

bhauman15:09:31

let me fix this

bhauman15:09:52

such good stuff

pesterhazy15:09:12

to confirm our hypothesis this fixes the bug

diff --git a/scripts/tests b/scripts/tests
index 97bd0d9..13d3401 100755
--- a/scripts/tests
+++ b/scripts/tests
@@ -1,10 +1,12 @@
 #!/usr/bin/env bash
 set -euo pipefail && cd "$(dirname "${BASH_SOURCE[0]}")/.."

 if [[ "${1-}" == "--reset" ]]; then
     rm -rf target doublebundle/dist
 fi

 doublebundle/scripts/rebuild-double-bundle

+mkdir -p target
+
 clj -m figwheel.main -co dev.cljs.edn -m cljs-spa.test-runner

pesterhazy15:09:02

still doesn't auto-discover the tests though :thinking_face:

Opening URL 

Testing cljs-spa.test-runner

Ran 0 tests containing 0 assertions.
0 failures, 0 errors.
:figwheel.main.testing/success

bhauman15:09:34

is the tests directory on your classpath?

bhauman15:09:44

are the tests on your classpath?

pesterhazy15:09:14

yes, in :paths and :watch-dirs

bhauman15:09:14

yeah of course they are

bhauman15:09:58

well there is probably a bug there somewhere as well

pesterhazy15:09:33

(run-tests-async 10000 'cljs-spa.core-test) works but (run-tests-async 10000) doesn't (no other changes)

bhauman15:09:58

I may have to give up on auto-detection if it doesn’t pan out

pesterhazy15:09:32

personally I think specifying the nss manually it totally fine

pesterhazy15:09:51

it's what we do with doo etc. as well

pesterhazy15:09:10

but of course it would be nicer if auto-detection worked reliably!

bhauman15:09:39

Did you try to use headless chrome yet?

pesterhazy16:09:43

Trying that now

bhauman16:09:28

yeah I’m trying to get away from using node to launch chrome for simple test runs

bhauman16:09:13

for complex web driver like interactions it makes a lot of sense

bhauman16:09:59

but the cool thing is with :launch-js you should be able to do all kinds of stuff like that

bhauman16:09:15

start a web server and any other processes you need and then run a web-driver test suite of some kind

pesterhazy16:09:55

Save for test autodetection, the auto-runner works really well

pesterhazy16:09:04

Headless or headful

bhauman16:09:34

@pesterhazy just deployed the target directory fix

pesterhazy16:09:44

One thing that's missing for my use case is that ideally the test runner output would include the script's console output, so you can debug unexpected problems. Karma/doo gives you that

pesterhazy16:09:21

will try the target dir fix tomorrow

pesterhazy16:09:32

thanks for fixing things so fast!

bhauman16:09:55

Thanks for testing things out, I’m trying to get this out the door soon.

bhauman16:09:21

I’d also like to get your feedback on the :auto-testing if you have time.

bhauman16:09:02

I’m going to look at messaging when nothing is configured to start a JavaScript environment.

pesterhazy16:09:17

will give it a spin tomorrow

pesterhazy16:09:21

I'm not sure how you're talking to Chrome so I don't know how much work it would be to implement sending console output, stacktraces etc. back to the test runner process

bhauman16:09:41

Yeah I’m guess I’m thinking of using the full fledged environment when debugging tests, and the single run as a canary that’s used for CI and before deployment etc

bhauman16:09:22

cause you really want an interactive flow when you are trying to sort something out

bhauman16:09:38

you don’t want to be running a single test run over and over when you are sorting out a problem

bhauman16:09:39

@pesterhazy thanks for the help

bhauman16:09:13

deployed a fix for the messaging when no js env is being launched

bhauman18:09:45

@pesterhazy fixed and deployed test namespace auto-detection