Fork me on GitHub
#figwheel-main
<
2018-07-24
>
ingesol08:07:41

Hi! I'm working on a friendly beginner experience for https://github.com/ingesolvoll/kee-frame, specifically configuration errors, function argument specs etc. It would be very nice to plug these into the figwheel error viewer. Is that something that is practically possible, or even desirable? My first idea was to "steal" the figwheel markup and write the logic myself, but the thought of plugins for figwheel sounds pretty appealing to me 🙂

plexus12:07:13

I'm evaluating if we can replace figwheel-sidecar with figwheel-main, this is for http://nextjournal.com. We have a handful of separate builds, some for the browser, one that targets node, one that runs in webworker. What we did before was start/stop figwheel from Integrant, and then have (${build-id}-cljs-repl) functions to switch to a particular REPL.

plexus12:07:52

Looking at figwheel.main/start, it seems it's not possible to start the building/watching and then switch to a REPL later on. It also doesn't seem possible to stop the ring server once it's started, so we can't do a restart short of killing the process.

plexus12:07:18

Should we use lower level APIs to achieve this? Are there any changes planned to make this kind of setup easier?

bhauman13:07:26

@plexus I haven't created the REPL API yet. I have an issue for that. The REPL switching part is interesting and currently harder. If you are wanting start stop the figwheel ring server, I'd suggest that you have your own ring-server at that point.

bhauman13:07:40

but bottom line is that figwheel-main is not there yet

bhauman13:07:15

need to think about a global datastructure and API that will facilitate these things

plexus13:07:51

Thanks, that's good to know. Thank you for all the hard work! We'll stick with sidecar for the time being then.

bhauman13:07:44

@ingesol unfortunately the figwheel-main heads up display is part of a state-machine that tracks the state of the build, so inserting new messages is tough

bhauman13:07:00

also messages for runtime errors is still an unsolved problem

bhauman13:07:19

its kinda difficult to get right

bhauman13:07:51

when I say unsolved I mean I haven't come up with a solution that I'm satisfied with that is better than printing to the console

ingesol15:07:51

@bhauman Right, I was probably naive to think that having this level of feedback is just a bit of yellow ink and a message 🙂

aisamu18:07:54

Are there plans to merge build files like we merge compile options? We have a bunch of builds that share a good chunk of parameters. Alternatively, since -co is merge-able, is there a way to set a -co for -bb?

defn21:07:04

New to figwheel-main, using vim, so I configured clojure-force-accept-line in rebel-readline to send the form whenever I pressed enter. Now I see that this prevents vim-slime from copy-pasting multi-line forms into my fingerwheel in a tmux pane. Starting to get it

bhauman21:07:44

@aisamu builds merge -b dev:other-build

👌 4
bhauman21:07:31

you can validate it's behavior with -pc -b dev:other-build

aisamu21:07:12

Oh, thanks! Will do

bhauman21:07:18

yeah I have to add this to the help

aisamu21:07:48

I'm assuming that works with -bb as well, right?

bhauman21:07:32

good question

bhauman21:07:45

@aisamu doesn't look like it

bhauman21:07:35

actually it doesn't seem to work

bhauman21:07:48

on -b either

bhauman21:07:39

@iam yeah we spent a bunch of time working on this

bhauman21:07:46

to get it right

bhauman21:07:03

its not perfect because we can't do a preferable command like shift-enter

aisamu21:07:25

Hm... that was my intended "target", since I can already execute merges on the "main" build with a -co edn1 edn2 -c instead of the -b. I couldn't find another way of merging options for background builds.