@eyelidlessness: figwheel compilation exceptions and warnings only go to the client and the figwheel_server.log

Not sure I understand your second comment about the only way to get output.

Was talking about producing output in the repl from, e.g. a fs watcher. I ended up being able to do so by sending a message to the client then printing from there.

but all may be moot with the notify-command PR, if you accept it

Didn't see that yet

https://github.com/bhauman/lein-figwheel/pull/307 - it turned out to be super simple

(apologies for the whitespace noise, my editor does that on save)

ClojureScript.java.shell!,

well, clojure.java.shell

@eyelidlessness: I wonder if we should just have a :notify-fn much more general

Yeah typo

as in, call an arbitrary clj function?

Yep

it may be confusing to have something similar to, but not the same as, cljsbuild, sitting in a cljsbuild config param

i could see it both ways, and certainly the clj function would be more idiomatic

i already feel strange having an arbitrary shell call in :test-commands

It seems that it would be more useful

But less [email protected]@this case

Hard to type on an iPad

ultimately either one can accommodate the other

Doesn't really go both ways though

We could have both one being a specialization of the other

imo supporting :notify-command is nice because it is what i expected when running figwheel with cljsbuild config. supporting an arbitrary on-compile fn would also be nice, but from the figwheel config so as not to confuse cljsbuild users

Just so you know, the intention is not to follow and support changes in cljsbuild functionality. It's just a convenient source of config information. You can place your :builds in the :figwheel config in fact I'm debating about making this the implicit default in the docs so that folks aren't confused about these things

i guess to me, supporting it partially is confusing and unexpected.

Yeah

I get it

Figwheel initially used cljsbuild and hooked into it

right

So it's a legacy thing

perhaps the right course of action is to deprecate it and focus on the figwheel api in docs?

It's probably time to do that

You mean the REPL api?

i mean the project config api. i actually wasn't even aware you could specify :builds

granted my introduction to figwheel came through installing the reagent template

which has its own (somewhat hodgepodge) opinions of project config

Well you can also have a figwheel.edn now ;)

Things are still unstable in terms of best practices.

having so many ways to do things is also confusing, but that honestly is a frustration i have with project.clj in general

Documentation gets much easier as things stabilize

i do prefer having my project configured in one place tho

BTW thanks for the PR I'm going to pull it in now :) I really appreciate it.

cheers!

it looks like you release fairly frequently too

Hi, sorry for noob question but could someone redirect me to some tutorial about deploying figwheel clojurescript project to server? I created ring handler in separate clj file in project and added key in figwheel configuration :ring-handler but what now? I also tried adding ring plugin to project.clj and then creating jar by lein ring uberjar. Server starts, sees my index.html but not compiled .js file 😕