Fork me on GitHub
#figwheel-main
<
2020-05-27
>
athomasoriginal00:05:58

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

athomasoriginal00:05:20

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

athomasoriginal00:05:30

Hope that helps 🙂

bhauman00:05:00

its fantastic thanks!

4
plexus11:05:46

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?

plexus11:05:46

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

plexus12:05:42

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.

bhauman12:05:06

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

bhauman12:05:44

actually this is a good question

bhauman13:05:23

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

plexus13:05:14

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

plexus13:05:22

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.

plexus13:05:31

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

plexus13:05:06

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

bhauman13:05:10

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

bhauman13:05:21

to overcome this obstacle

bhauman13:05:00

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

bhauman13:05:27

I should have done that sooner

plexus13:05:36

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

bhauman13:05:12

oh geez its early here, I missed that

plexus13:05:29

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.

bhauman13:05:09

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

plexus13:05:56

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 🙂

plexus13:05:15

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

bhauman13:05:07

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

dominicm15:05:57

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

dominicm15:05:05

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

dominicm15:05:24

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.

bhauman15:05:46

and they can 🙂

bhauman15:05:09

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

dominicm15:05:26

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.

bhauman15:05:38

I get that

dominicm15:05:41

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

bhauman15:05:18

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

dominicm15:05:27

OK, that makes more sense to me now :)

bhauman15:05:30

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

bhauman15:05:01

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

bhauman15:05:21

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

dominicm15:05:21

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

dominicm15:05:41

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

bhauman15:05:47

which is awesome (th override)

bhauman15:05:09

not just for that but for the default repl html page

dominicm15:05:45

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

bhauman15:05:14

check the command on the command line?

dominicm15:05:30

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

bhauman15:05:58

yep that’s the default

dominicm15:05:35

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

bhauman15:05:45

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

bhauman15:05:09

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

dominicm15:05:26

Oh yes, I see.

dominicm15:05:38

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

bhauman15:05:01

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

dominicm15:05:21

It makes sense :)

dominicm15:05:39

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

dominicm15:05:45

Great, that works!

bhauman15:05:27

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

dominicm15:05:28

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

dominicm15:05:04

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

dominicm15:05:18

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

bhauman15:05:30

not sure I understand which optimizations your talking about @dominicm

dominicm15:05:20

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

dominicm15:05:47

probably worth bundling when package.json changes too btw.

dominicm15:05:57

e.g. if I upgrade react.

bhauman15:05:05

@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

dominicm15:05:54

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

dominicm15:05:09

It has native websocket support.

bhauman15:05:44

what’s the timeline on that?

bhauman15:05:50

and its still jetty right?

dominicm15:05:21

Ring doesn't care about jetty.

bhauman15:05:46

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

dominicm15:05:40

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

bhauman15:05:41

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

bhauman15:05:22

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

dominicm15:05:19

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

bhauman15:05:26

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

dominicm15:05:47

The clojurescript browser implementation is interesting.

bhauman16:05:06

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

bhauman16:05:43

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

dominicm16:05:20

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

bhauman17:05:20

interesting

dominicm16:05:26

And you can polyfill it

dominicm16:05:38

Might be worth building something based on that

dominicm17:05:46

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

bhauman17:05:10

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

bhauman17:05:34

sounds a lot like long polling

dominicm17:05:38

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

dominicm17:05:00

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

bhauman17:05:45

yeah makes sense, its a good idea

dominicm17:05:30

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

bhauman17:05:39

yeah, its cool though

bhauman23:05:25

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

👍 20
🎉 8
bhauman23:05:02

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