Fork me on GitHub
#boot
<
2017-11-25
>
sparkofreason00:11:32

No. It's [prismatic/schema "1.1.6"].

richiardiandrea00:11:28

uhm, it looks like it leaks in some exception

richiardiandrea00:11:30

boot-cljs executes things in a pod so I don't know if you can hook into that Juho knows more

sparkofreason00:11:42

I actually hacked it to println the exception from inside the pod, so problem solved for now. Thanks.

athomasoriginal00:11:55

Are there any resources outlining how to get started with figwheel using boot? My concern is that it is somehow geared towards lein and the setup is difficult/not 100% possible. Is this true?

richiardiandrea00:11:09

@tkjone maintainer of boot-figreload here, there are two ways of getting reload with boot: the most battle tested is boot-reload, it's been around for longer and stable. HUD output is similar but not exactly the same. That is why I came up with a way to use the awesome client side only part of figwheel for boot-figreload. About the setup, there are templates that set everything up for you, or you ask here and somebody will guide you through the process (oh...actually there is a setup right above this comment).

athomasoriginal14:11:49

Thanks! I have seen both boot-figreload and boot-reload but I was not sure how they compare to one another. From your explanation, it seems that boot-figreload add the front end experience to match what figwheel does, yes? How do they differ?

athomasoriginal16:11:17

For further clarification, it seems like figwheel is not an option with boot. Instead, boot has created a task that will simulate some/all of the figwheel behaviour, yes? Or, like boot-figreload is boot-reload using some of the figwheel src internally?

richiardiandrea16:11:50

So boot-reload has its own reloading and display HUD, while boot-figreload uses figwheel's HUD directly.

athomasoriginal16:11:21

Just for my own clarification (apologies) - does boot-figreload rely on boot-reload as a dependency in any way?

athomasoriginal16:11:11

I suppose what I am trying to fit into my mental model is that figwheel seems to be a strong selling point for clojurescript. However, it appears to be coupled with lein. So, in order to get the functionality that figwheel provides with boot, the boot community has created their own tasks. The question becomes, do the boot tasks have near 100% parity of functionality with figwheel? I see that your boot-figreload is using the front end component - which seems to mean that a lot of those great features from figwheel are available in boot because you are actually using parts of figwheel. The end question being, does using boot result in a CLJ/S developer being blocked (so to speak) from using all the magic that is figwheel?

richiardiandrea18:11:49

I guess the only way to answer properly is : which features are you referring to? The Readme explains what it's there

richiardiandrea18:11:01

The error display is the same

richiardiandrea18:11:32

And no it does not depend on boot-reload

athomasoriginal18:11:23

Based on the features outlined in the fighweel README here https://github.com/bhauman/lein-figwheel I would be looking for everything minus the node supprt (that is not a primary concern)

athomasoriginal18:11:08

I reviewed features provided by the boot tasks, but they are using different naming conventions compared to figwheels README, so it is not obvious (to me) the level of feature parity.

richiardiandrea22:11:26

Maybe give it a go with one template like tenzing or the re-frame one. Make sure to report what you miss in the repos

athomasoriginal15:11:12

Apologies if this is documented by boot, but I don't understand what the :scope "test" part of the following line in the :dependencies config property for a build.boot file.

[adzerk/boot-reload "0.5.1" :scope "test"]
I see it in some template and in others I do not. An example of where I have seen this: https://github.com/martinklepsch/tenzing/blob/master/resources/leiningen/new/tenzing/build.boot

athomasoriginal16:11:41

So this would be the equivalent of npm's devDependencies. Makes sense. Thanks @juhoteperi!