athomasoriginal 2020-05-27T00:00:58.433400Z

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

athomasoriginal 2020-05-27T00:01:20.433900Z

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

athomasoriginal 2020-05-27T00:01:30.434200Z

Hope that helps 🙂

bhauman 2020-05-27T00:02:00.434900Z

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.

plexus 2020-05-27T11:09:46.437500Z

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?

plexus 2020-05-27T11:10:46.438200Z

I'd like to provide instructions for people on how to use chui ( with Figwheel, so far I've only tested it with shadow-cljs

plexus 2020-05-27T12:04:42.440Z

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.

bhauman 2020-05-27T12:52:06.440900Z

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

bhauman 2020-05-27T12:54:44.442300Z

actually this is a good question

bhauman 2020-05-27T13:00:26.443100Z

@plexus these instructions should work right?

bhauman 2020-05-27T13:05:23.445300Z

@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?

plexus 2020-05-27T13:08:14.446200Z

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

plexus 2020-05-27T13:09:22.447200Z

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.

plexus 2020-05-27T13:10:31.448100Z

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

plexus 2020-05-27T13:11:06.448600Z

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

bhauman 2020-05-27T13:13:10.449100Z

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

bhauman 2020-05-27T13:13:21.449400Z

to overcome this obstacle

bhauman 2020-05-27T13:15:00.450600Z

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

bhauman 2020-05-27T13:16:27.451900Z

I should have done that sooner

plexus 2020-05-27T13:16:36.452200Z

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

bhauman 2020-05-27T13:17:12.452600Z

oh geez its early here, I missed that

plexus 2020-05-27T13:18:29.454700Z

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.

bhauman 2020-05-27T13:21:09.457Z

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

plexus 2020-05-27T13:21:56.458Z

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 🙂

plexus 2020-05-27T13:22:15.458800Z

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

bhauman 2020-05-27T13:27:07.462100Z

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

dominicm 2020-05-27T15:08:57.463900Z

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 :)

dominicm 2020-05-27T15:10:05.464Z

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 :).

bhauman 2020-05-27T15:10:54.464400Z

@dominicm in what way?

dominicm 2020-05-27T15:11:24.465200Z

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.

bhauman 2020-05-27T15:11:46.465400Z

and they can 🙂

bhauman 2020-05-27T15:12:09.465900Z

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

dominicm 2020-05-27T15:12:26.466100Z

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.

bhauman 2020-05-27T15:12:38.466300Z

I get that

dominicm 2020-05-27T15:12:41.466500Z

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

bhauman 2020-05-27T15:12:46.466700Z


bhauman 2020-05-27T15:13:18.467300Z

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

dominicm 2020-05-27T15:14:27.468600Z

OK, that makes more sense to me now :)

bhauman 2020-05-27T15:14:30.468700Z

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

bhauman 2020-05-27T15:15:01.469400Z

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

bhauman 2020-05-27T15:15:21.469800Z

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

dominicm 2020-05-27T15:15:21.469900Z

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

dominicm 2020-05-27T15:15:41.470200Z

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

bhauman 2020-05-27T15:15:47.470400Z

which is awesome (th override)

bhauman 2020-05-27T15:16:09.471Z

not just for that but for the default repl html page

dominicm 2020-05-27T15:16:45.471500Z

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

bhauman 2020-05-27T15:17:14.471800Z

check the command on the command line?

dominicm 2020-05-27T15:17:30.472100Z

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

bhauman 2020-05-27T15:17:58.472500Z

yep that’s the default

dominicm 2020-05-27T15:18:35.473300Z

{: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}   
But I told it to put it somewhere else :)

bhauman 2020-05-27T15:18:45.473500Z

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

bhauman 2020-05-27T15:19:09.474Z

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

dominicm 2020-05-27T15:19:26.474200Z

Oh yes, I see.

dominicm 2020-05-27T15:19:38.474600Z

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

bhauman 2020-05-27T15:20:01.475Z

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

dominicm 2020-05-27T15:20:21.475300Z

It makes sense :)

dominicm 2020-05-27T15:20:39.475700Z

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

dominicm 2020-05-27T15:20:45.475900Z

Great, that works!

bhauman 2020-05-27T15:21:27.476700Z

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

dominicm 2020-05-27T15:22:28.476800Z

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

dominicm 2020-05-27T15:23:04.477200Z

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

dominicm 2020-05-27T15:23:18.477300Z

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

bhauman 2020-05-27T15:24:10.477500Z


bhauman 2020-05-27T15:24:30.478Z

not sure I understand which optimizations your talking about @dominicm

dominicm 2020-05-27T15:25:20.478100Z

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

bhauman 2020-05-27T15:25:37.478300Z

oh gotcha

dominicm 2020-05-27T15:25:47.478600Z

probably worth bundling when package.json changes too btw.

dominicm 2020-05-27T15:25:57.478900Z

e.g. if I upgrade react.

bhauman 2020-05-27T15:52:05.480800Z

@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

dominicm 2020-05-27T15:52:54.482300Z

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

dominicm 2020-05-27T15:53:09.482800Z

It has native websocket support.

bhauman 2020-05-27T15:53:27.483100Z

oh, dang

bhauman 2020-05-27T15:53:44.483400Z

what’s the timeline on that?

bhauman 2020-05-27T15:53:50.483700Z

and its still jetty right?

dominicm 2020-05-27T15:54:21.484300Z

Ring doesn't care about jetty.

bhauman 2020-05-27T15:54:46.484900Z

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

dominicm 2020-05-27T15:55:16.485300Z

dominicm 2020-05-27T15:55:40.486200Z

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

bhauman 2020-05-27T15:57:41.487Z

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

bhauman 2020-05-27T15:58:22.487800Z

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

dominicm 2020-05-27T15:59:19.489600Z

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

bhauman 2020-05-27T15:59:26.489800Z

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

dominicm 2020-05-27T15:59:47.490300Z

The clojurescript browser implementation is interesting.

bhauman 2020-05-27T16:01:06.491700Z

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

bhauman 2020-05-27T16:01:43.492500Z

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

dominicm 2020-05-27T16:05:20.493800Z

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

dominicm 2020-05-27T16:05:26.494100Z

And you can polyfill it

dominicm 2020-05-27T16:05:38.494500Z

Might be worth building something based on that

bhauman 2020-05-27T17:03:20.494800Z


dominicm 2020-05-27T17:04:46.495800Z

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

bhauman 2020-05-27T17:11:10.497Z

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

bhauman 2020-05-27T17:13:34.498100Z

sounds a lot like long polling

dominicm 2020-05-27T17:13:38.498300Z

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

dominicm 2020-05-27T17:14:00.499300Z

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

bhauman 2020-05-27T17:15:45.000500Z

yeah makes sense, its a good idea

dominicm 2020-05-27T17:15:48.000600Z third party client.

dominicm 2020-05-27T17:16:30.001900Z

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

bhauman 2020-05-27T17:18:39.002500Z

yeah, its cool though

bhauman 2020-05-27T23:08:25.003500Z

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

bhauman 2020-05-27T23:08:32.003700Z

bhauman 2020-05-27T23:09:02.004400Z

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