Clojurians Log v2

Everything works. The guide is great. The only possible items of confusion might be in the QuickStart.

I know that is a balancing act though because it’s easy to say too much too early

Hope that helps 🙂

its fantastic thanks!

@bhauman I tried out the new version with debug logging and it gives me a lot more useful information. Awesome. Thanks again.

is it possible to get the benefits of figwheel's :auto-testing (i.e. automatic detection/injecting of test namespaces) while supplying a custom test runner namespace?

I'd like to provide instructions for people on how to use chui (https://github.com/lambdaisland/chui) with Figwheel, so far I've only tested it with shadow-cljs

but it relies quite heavily on the fact that shadow injects your test namespaces as dependencies of the runner ns. If you need to manually require all those tests that's not a great user experience. I was wondering if it's possible to do the same figwheel, or maybe even if it's something to lobby for at the cljs compiler level.

@plexus auto-testing is just syntax sugar over extra-mains functionality

actually this is a good question

@plexus these instructions should work right? https://figwheel.org/docs/testing.html#custom-testing-with-extra-main-files

@plexus I think I need to make a utility macro to allow you to pull all of the test namespaces. But you could give folks instructions where they supply the namespaces as well right?

@bhauman yeah I read those instructions, but they mention requiring your test namespaces manually, which worried me a bit :)

chui has a macro which collects information about test vars from the compiler env, so it's important that that only gets compiled after all the test namespaces are compiled.

on shadow we can supply the runner namespace as part of chui, but then shadow implicitly does the requires, so those test namespaces are compiled first

users would have to copy that runner namespace into their own projects to be able to add requires manually

so figwheel does and initial scan of the watch-dirs to gather test namespaces

to overcome this obstacle

@plexus if I provided you a helper that returned the test-namespaces at cljs runtime, that’s all you need right?

I should have done that sooner

uh you'll have to walk me through here. How would that work? Would that allow me to then require those namespaces automatically?

oh geez its early here, I missed that

yeah that's really the crux of the matter here. We collect pretty detailed information about test vars from the compiler env, but to do that we have to be sure that all test namespaces have been compiled first, so they need to implicitly (or explicitly) required before that macro that collects test information runs.

https://github.com/lambdaisland/chui/blob/master/modules/chui-core/src/lambdaisland/chui/test_data.clj#L50

hmmm I’ll need to reflect on this, but there should be a strategy where you can use chui with cljs.main right?

yeah same issue... which is why I was thinking maybe this conversation should be had in #cljs-dev, not sure how receptive they'll be over there 🙂

I mean people can always supply their own main ns that just calls into chui, and do manual requires, that always works

yeah let me put it on my list to look at this

Something unclear to me from reading the new npm page in isolation is what my :output-to should be set to? Should it be set to the name of the file I am serving (frontend.js) or the name of the file I'm currently passing to webpack (index.js). I suspect it should be frontend.js, and the :output-to used in the bundle-cmd is not the :output-to I set in my config, but that's a bit confusing :)

I should read more carefully :) > Figwheel adds some additional functionality to the :bundle-cmd. It interpolates the keywords :output-to and :final-output-to into the command. In this case the :output-to is going to be replaced by the default :output-to path target/public/cljs-out/dev/main.js. The :final-ouput-to is replaced by the default value of :output-to with a bundle added before the extension or target/public/cljs-out/dev/mainbundle.js. Having said that, I'm not sure this way makes sense either :).

@dominicm in what way?

I think most uses are going to have/want to specify the :final-output-to if they don't want to leak "internal details" of their build throughout.

and they can 🙂

^{:final-output-to “this/output.js”}{:main …}

I also don't care about :output-to at all anymore. It's just a transient file. It could be in /tmp/ for all I care.

I get that

I suppose I don't really need to specify it :thinking_face:

exactly

figwheel.main always handles the :output-to if you don’t specify it

OK, that makes more sense to me now :)

we can’t really have :output-to be the bundled output

because lots of folks are going to have a webpack.config

and we won’t even know the final-output file

you can have both, the cli argument will override the webpack config.

Also, knowing the final-output is a prerequisite to extra mains I assume?

which is awesome (th override)

not just for that but for the default repl html page

Hmph. My final-output-to is not being written.

check the command on the command line?

The bundle is being written to <output-dir>/main_bundle.js,

yep that’s the default

{:output-dir "target/dev/public/frontend.out",                                                                                                                    
 :language-out :es5,                                                                                                                                              
 :asset-path "/frontend.out",                                                                                                                                     
 :bundle-cmd {:none ["npx" "webpack" "--mode=development" :output-to "-o" :final-output-to]},                                                                     
 :final-output-to "target/dev/public/frontend.js",                                                                                                                
 :target :bundle,                                                                                                                                                 
 :main frontend.main}   

you can override that with :final-output-to figwheel-option or just add it do the command

:final-output-to is a Figwheel option not a cljs option 😞

Oh yes, I see.

I should probably co-locate my cljs & figwheel config.

yeah I try to keep the figwheel options out of the cljs options

It makes sense :)

It's difficult for the way I've laid out my interaction with the API is all

Great, that works!

but you could just skip final-output-to and put it directly in the command because your not using the default repl or extra-mains etc

yet :) I think devcards may be on the horizon.

Well, I'm 22 loc lighter (as I no longer build a process for webpack in watch mode). So I'm pretty happy :)

Looking forward to free optimizations to come downstream around npm_deps.js caching & such.

??

not sure I understand which optimizations your talking about @dominicm

> I’m going to add smart bundling based on index.js and npm_deps.js file next and put it behind a flag

oh gotcha

probably worth bundling when package.json changes too btw.

e.g. if I upgrade react.

@dominicm I’ve been thinking a lot about the jetty conflicts that people experience so often, I’d love to be able to get away from that

@bhauman not sure if you're tracking ring 2.0 or not, but I think your life will be better once it's out

It has native websocket support.

oh, dang

what’s the timeline on that?

and its still jetty right?

Ring doesn't care about jetty.

yeah but you need an adapter and the default adapter is jetty

https://github.com/ring-clojure/ring/issues/393

The adapter most people use is jetty, yeah. But this should make it easier to swap between servers.

I guess my biggest question is are you attached to jetty in your use of figwheel?

because I’ve been thinking of going back to http-kit bc there are no dep conflicts

Not at all. The web server I use is netty/aleph

or just rolling a simple server by hand and using long polling instead of websockets as it works just fine

The clojurescript browser implementation is interesting.

yeah and it would pretty be straight forward to add long polling comet stuff to that and then we’re out of the websocket game

that’s a big change but the simplicity!!!

It's a shame IE never added official support for server sent events, it's much simpler of a protocol than WS

And you can polyfill it

Might be worth building something based on that

interesting

SSE has lots of nice properties, like automatic reconnection based on network conditions. All handled by the browser.

yeah, but the nice thing about websockets is they are supported in react-native, node.js, browser etc. can we say that about SSE?

sounds a lot like long polling

Not seeing a client. Had forgotten that Figwheel tries to be everything.

It's a little better than long polling, because it's a persistent connection.

yeah makes sense, its a good idea

https://github.com/EventSource/eventsource third party client.

But I think this idea is probably a dud. Long polling is well established from a client perspective. The complexity gets pushed into the server to manage things though

yeah, its cool though

I’ve been putting a lot more work in the the NPM docs

https://figwheel.org/docs/npm.html

probably lots of typos, I still haven’t got to advanced compilation yet