Fork me on GitHub
#figwheel-main
<
2018-09-18
>
richiardiandrea01:09:07

@dpsutton nRepl should write an port file in the current folder and Cursive should be able to connect to it when selecting the Lein REPL option - see here: https://andrearichiardi.com/blog/posts/clojurescript-cursive-shadow-setup.html

dpsutton01:09:38

Thanks. I'll tell him to look for that

richiardiandrea01:09:13

If there is no file maybe he's got an old version

richiardiandrea01:09:39

It might depend on how clj or figwheel launch nRepl actually. Haven't explored that part

plexus09:09:53

Figwheel should work with Node.js just fine, right? I'm getting these errors after migrating to figwheel.main

plexus09:09:56

[nodejs:out]  [goog.net.WebSocket] Opening the WebSocket on 
[nodejs:out]  [goog.net.WebSocket] The WebSocket on  closed.
[nodejs:out]  [  2.952s] [goog.net.WebSocket] The WebSocket on  closed.
[nodejs:out]  [goog.net.WebSocket] Seconds until next reconnect attempt: 1
[nodejs:out]  [  2.953s] [goog.net.WebSocket] Seconds until next reconnect attempt: 1
[nodejs:out]  [goog.net.WebSocket] Opening the WebSocket on 
[nodejs] Exited with error code 1.
[nodejs:err]  [goog.net.WebSocket] An error occurred: undefined
[nodejs:err]  [  2.950s] [goog.net.WebSocket] An error occurred: undefined
[nodejs:err]  [goog.net.WebSocket] The WebSocket disconnected unexpectedly: undefined
[nodejs:err]  [  2.953s] [goog.net.WebSocket] The WebSocket disconnected unexpectedly: undefined

gdanov10:09:00

has anyone had success to run :nodejs extra-main on browser project? I can't mix the two with extra-main

gdanov16:09:16

@bhauman — am I missing something? read the doc and it has no extra instructions

bhauman17:09:58

@U051GJCF0 yeah that probably won’t work

bhauman17:09:12

extra-mains stays in the same build

bhauman17:09:42

the same compile options compile everything

gdanov18:09:27

that's also the conclusion I came to eventually, but hoped there's some magic...anyway, thanks, happy nonetheless

bhauman22:09:53

@U051GJCF0 I’m just about to get this to work 🙂

kwladyka10:09:09

I have questions about testing. It could also help to provide more info to https://figwheel.org/docs/testing.html - (run-tests-async 10000) - what if one of tests will take 15 sec.? Will it fail or success? - It works without defmethod report [:cljs.test/default :end-run-tests] [test-data]. It makes me confuse. Do I need declare this method or not? If not so what is the point of declaring this method?

kwladyka11:09:01

ok I think I can answer myself from the source code: - it is timeout so it will fail after 10 sec.

kwladyka11:09:30

but not sure about this method

kwladyka11:09:05

clj -A:fig -m figwheel.main -m form-validator.test-runner open web browser window. What I miss? It shouldn’t happen. At least as I understand doc https://figwheel.org/docs/testing.html#running-tests-from-the-command-line

kwladyka11:09:21

and how to make it to watch changes in code and re-run tests in console?

kwladyka11:09:03

^{:watch-dirs ["src" "admin-src"]
  :css-dirs ["resources/public/css"]}
{:main example.core}
Why :main is in separated map? What are other parameters besides of :main in this second map?

kwladyka11:09:55

Hmm or maybe this part of the doc doesn’t mean tests are run in console. Still web browser is needed. > Running tests from the command line This could explain my confusion

kwladyka11:09:45

so… figwheel-main has no functionality to run tests in console without web browser. Am I right?

plexus12:09:08

@kwladyka doo is also a popular option for running CLJS tests

kwladyka12:09:18

cljs-test-runner use doo under the hood

bhauman12:09:45

@kwladyka running tests from the command line also supports headless testing

bhauman12:09:12

@kwladyka you have to tell it what environment to test ing

bhauman12:09:34

that’s why its describes how to do this at the bottom of the document

bhauman12:09:56

folks are making a lot of assumptions about testing, I’m going to need to clarify the document

kwladyka12:09:06

Hmm so how should I run it to run tests in console?

kwladyka12:09:22

the example is about run in chrome

bhauman12:09:30

headless chrome

bhauman12:09:42

which doesn’t open a window

kwladyka12:09:01

oh that is what it means

kwladyka12:09:52

Still it looks complex to run console tests vs cljs-test-runner

bhauman12:09:07

yeah don’t do that

bhauman12:09:27

follow the instructions I linked to

bhauman12:09:37

its much much much easier

bhauman12:09:54

cljs-test-runner is not easy

kwladyka12:09:19

Why? It works immediately without my effort

kwladyka12:09:40

It is super easy, unless I miss something

bhauman12:09:59

oh well if it works for you that’s great

kwladyka12:09:01

test-runner

(ns form-validator.test-runner
  (:require [form-validator.core-test]))
It is whole code to run tests, no more needed, even 1 extra line (body). It detects things by automate.

kwladyka12:09:31

so that is why I am asking about fighweel-main, beucase it is important for CI purpose

kwladyka12:09:54

I mean `:launch-js [“/Applications/Google Chrome.app/Contents/MacOS/Google Chrome” “--headless” “--disable-gpu” “--repl” :open-url]` this part sounds like a lot of troubles

bhauman12:09:26

did you read the whole thing?

bhauman12:09:56

it can run your tests with a script or with that command or even a clojure function

kwladyka12:09:02

Yes, but maybe I misunderstood it

bhauman12:09:20

the idea is you can use it to run your tests with anything that runs javascript

bhauman12:09:43

and since there are so many ways to do that, it lets you choose

kwladyka12:09:03

So how should I run js tests in simple way in console?

bhauman12:09:42

its OK if this isn’t simple for you

bhauman12:09:09

and I think we are missunderstanding eachother

bhauman12:09:26

tests will run in a browser

kwladyka12:09:37

I would agree if you say “it is ok if this isn’t easy for you”, but with simple I would argue 🙂

bhauman12:09:00

simple is an overloaded term

bhauman12:09:05

in the Clojure Community

plexus12:09:45

@bhauman thanks for all the work on figwheel.main, this time around we managed to migrate from sidecar pretty smoothly

kwladyka12:09:17

As I understand it needs to know a path to the chrome. On each system it can be different path. I don’t feel it. Just I would like to see common configuration for that purpose. *that - run tests in console on each developers computer and CI servers without issues

plexus12:09:42

I did run into [Figwheel:SEVERE] clojure.lang.ExceptionInfo: Circular dependency between foo.bar and foo.bar in a case where a .cljs namespace was loading macros from a .clj namespace with the same name

bhauman12:09:35

@kwladyka I think I’ll just have to say that this is as far as figwheel has made it into the testing space

bhauman12:09:47

it was a ton of work and I’m one developer

bhauman12:09:58

the solution offers flexibility

kwladyka12:09:45

@bhauman your work is great. I am saying that, because I want to learn how to use your tool in right way. Only one purpose. Maybe give feedback also. I hope you appreciate it.

bhauman12:09:49

@plexus did you figure out the node thing?

plexus12:09:14

it went away... working fine now. I probably did something wrong.

bhauman12:09:26

it sounded like a sidecar thing

bhauman12:09:12

@kwladyka since this testing support is brand new there is no best way yet

plexus12:09:28

when using :extra-main-files for devcards, do you still need :devcards true somewhere?

bhauman13:09:10

@plexus yes in the ClojureScript compile options

bhauman13:09:47

@kwladyka also I think you are wanting to run automated tests from the command line?

bhauman13:09:53

that re-run when files change?

bhauman13:09:18

or are you talking about just running them for CI?

kwladyka13:09:31

both, full needs about testing

bhauman13:09:41

@plexus you can also add “devcards.core/active true” to the :closure-defines

plexus13:09:13

ah cool, so this I can do just for a specific main file

bhauman13:09:19

@kwladyka I don’t have instructions available for running automated tests on the command line yet

bhauman13:09:11

@plexus that would have to be on the build

bhauman13:09:26

the extra mains don’t affect compilation

plexus13:09:58

right... so currently we have our defcard's in the same namespaces as components, but I guess we should split those out

bhauman13:09:52

@kwladyka you would add the :launch-js to a test.cljs.edn and then you would run clj -m figwheel.main -b test -r for automated tests

bhauman13:09:43

@plexus I would just have a separate build file for dev and prod at this point

kwladyka13:09:09

@bhauman great, so it will be update 🙂 I will wait for the doc 🙂 I can’t figure out myself how to do re-run with watch and CI run without knowing path to chrome.

bhauman13:09:48

@plexus not sure about the circular dep problem

plexus13:09:41

I fixed it by renaming the macro namespace to foo.bar.macros so that's fine

bhauman13:09:40

@plexus I’m happy to hear any feedback you have on figwheel.main

bhauman13:09:52

so never hesitate to hit me up

bhauman13:09:28

you should find that it works much much better than figwheel

plexus13:09:40

will keep you posted as we start using it. So far the only thing that I've missed is a way to wrap the build-fn, worked around that by doing an alter-var-root on figwheel.main/fig-core-build

plexus13:09:31

we have five builds running at the same time, and we have some extra logic to skip rebuilds if the changed files aren't depended on by the build's :main namespace

bhauman13:09:03

yeah there should be a way to hook the build fn

bhauman13:09:28

it’s on one of my lists somewhere, if you want to file an issue that is fine with me

plexus13:09:01

the pre and post hooks are handy, there was something else we were using the build-fn for that I managed to do with a post hook, but for this use case you really need the build-fn

bhauman13:09:05

but alter var root does work 😉

plexus13:09:11

ok, I'll file an issue 🙂

bhauman13:09:48

@plexus also, is it possible to use extra-mains to eliminate some or all of these builds?

bhauman13:09:21

because there is nothing wrong with having all the code being shared during development

bhauman13:09:58

unless you are abusing namespaces

bhauman13:09:27

or are targeting node

plexus13:09:05

that's one of the reasons why we're switching, to try and eliminite some of them

plexus13:09:59

one targets node, so that one's out. One is a webworker, not sure if that changes things? One is for devcards, still need to figure out how to get the devcards UI in one main but not the other, and the final one has a custom :on-jsload, not sure yet how to deal with that.

bhauman13:09:38

I think the webworker will be fine

plexus13:09:39

ah, cool. So :on-jsload isn't really needed anymore

bhauman13:09:54

but … and I have to put this in the docs

bhauman13:09:36

with extra mains all the reloads will fire if they are present in the environment, so you will want to make them conditional

bhauman13:09:58

if the file isn’t loaded no problem

plexus13:09:07

that makes sense, I think only one will be loaded at a time but will keep an eye out

bhauman13:09:47

but I do think webworker will be fine as it only changes the generated main file

bhauman13:09:36

I think node compilation does output some rare things differently in the output namespaces

bhauman13:09:47

like FILENAME and such

bhauman13:09:15

but it is very possible that you could have node be an extra main as well

bhauman13:09:53

so it sounds like you could theoretically have one build

bhauman13:09:12

which would be very exciting

plexus13:09:07

indeed! that would make people very happy around here 🙂

plexus13:09:36

do you know why we're getting lots of these warnings?

plexus13:09:40

[Figwheel] Compile Warning   journal/src/editor/components/ui/autocompleter.cljs   line:250  column:1

Use of undeclared Var devcards.core/register-card

245     {:label "List" :value :list}
246     {:label "Code Listing" :value :code-listing}
247     {:label "Formula" :value :formula}
248     {:label "Image" :value :image}])
249
250  (defcard-rg autcompleter-dropdown
       ^---
251    (let [open? (reagent/atom false)
252          selected-value (reagent/atom :paragraph)]
253      (fn []
254        [:button.nj-button--primary.flex.items-center.mr2
255         {:on-click #(reset! open? true)

bhauman13:09:16

yes, this is the common devcards chicken and egg problem

bhauman13:09:57

try adding devcards.core to your preloads

plexus14:09:19

getting NS_BINDING_ABORTED: on the webworker... I think this might not work with the extra mains

plexus14:09:37

@bhauman that preload worked by the way once I had my source paths in order 🙂

plexus14:09:50

oh the web worker does seem to do its thing... nice!

bhauman14:09:36

oh yeah cooking with gas!! 🚀

4
pesterhazy17:09:57

New release of cljs-spa-example featuring simplified global exports configuration and automatic headless testing: https://github.com/pesterhazy/cljs-spa-example

👍 8
bhauman18:09:46

@pesterhazy I’d move some of the config parameters out of figwheel-main.edn to dev.cljs.edn

bhauman18:09:10

the ones that are specific to development

tmarble22:09:31

@bhauman i've made some progress with "fig:test" in my actual client environment 1. By adding "target" to the resource-paths then should-add-temp-dir? is false (and then ouput-dir is not changed. 2. In this environment adding "/test.html" just didn't work (even with a resources/public/test.html file in place) so in test.cljs.edn I left :open-url "http://[[server-hostname]]:[[server-port]]" 3. I can use a shell script (instead of a hardcoded pathname) to invoke the proper executable of Chrome based on the platform (e.g. Mac for devs, Linux for CI). The key thing to remember is it's really important to NOT pollute STDOUT (as the test may misinterpret garbage) and I have the script exec the chrome binary. In this way I no longer have to worry about saving the PID and killing the headless browser as it seems to quit properly (presumably via "quit" in the test session?)

tmarble22:09:17

That being said.. it seems like changing :output-dir and/or :output-to in test.cljs.edn causes the interactive (pipe) session to the headless chrome to not work correctly (so I make sure neither of those are set and just accept the defaults).

tmarble22:09:45

I wonder if anyone has tried to set :output-dir with the template AND had "fig:test" work successfully?

rgm22:09:25

I’m setting up a browser repl through vim/fireplace/piggieback and I’m pretty confused about the moving pieces … if I start up an nrepl process with nrepl/start-server and then start a figwheel build using figwheel.main.api/start, is piggieback somehow getting wrapped into that down in figwheel someplace?

rgm22:09:16

oh wait, or does the piggieback wrapping of NREPL come into effect only once I boot up the figwheel cljs-repl?