are extra mains compatible with using your own server? It would seem not to me. I'm using a custom asset path, which causes figwheel to be unable to server the js.

@dominicm extra mains will work with your own server, but you will need to create the landing page

Okay, makes sense. I had hoped to use figwheel as my auxiliary server for all dev tooling, but that seems less possible now.

not sure what that means??

I was going to put a bunch of random builds onto there, even some which were hard coded pages, just as a permanent server to host things.

Out of curiosity (and I think the answer is very) how hard would it be to bring figwheel's websocket server into my own server?

you wanted figwheel to server all tests devcards, etc

yeah. I even had some schemes involving it having a bookmarking "service" and similar.

yes the state of websockets in java is ugly right.

of course with some abstraction, we could make it easier but you will be coding the websocket endpoint for certain

but why not middleware in the figwheel server?

there’s nothing you can’t do via that route

coding the websocket part is fine by me, aleph's interface for this is rather nice.

No particular reason 🙂 that's probably the better option really. If it was easy enough, then it's nice to have only 1 port open rather than 2.

One factor is that I might want this to work with figwheel-sidecar and/or shadow, so my current thinking was a third server, which wasn't something I preferred.

yeah that makes sense

if ring had a websocket interface that was supported by the dominant webservers that would be fantastic

then this would all be trivial

I suppose a third-party ring extension could work...

(I should probably note that this is all in the context of our application framework rather than a single project - hence things like shadow support)

yep I get that

Anyway, thanks 🙂 figwheel-main has been really great in Edge. I've moved a few of our projects over from figwheel-sidecar, and things are generally much smoother. We're just starting to experiment with devcards, auto-testing, etc.

I'm wanting to do an "auto-mains listing" which links you to the auto-testing, devcards, etc. when you do (go), so figuring out where that will live is important.

I've coined the term "bruce shop" for a figwheel/devcards/cljs-test-display shop

We were able to impress a client who buzzword tests using cljs-test-display. The tests were mostly useless, but the client loved the UI.

lol

Hmm, hard to convey what I'm getting at there in a concise way. The client likes tests, but doesn't know when tests are useless and burdensome, so they just want to see lots of tests.

just deployed 0.2.1-SNAPSHOT which fixes warnings that started showing up with the recent compiler changes

thanks @mfikes