@neupsh no figwheel.main it doesn’t have this

@kwladyka I have verified that figwheel does indeed watch directories outside of the local project directory. This is on OSX, and all I’m doing is adding directories to watch-dirs:

@kwladyka if this isn’t happening for you please file a detailed issue, because I do want to support this

I remember I had an error path can’t be outside project directory about 2 months ago

I will check it soon again, thx

@dimovich I have not been able to reproduce this behavior, I am able to have multiple clients locally and non locally all receive reload broadcasts at the same time

@richiardiandrea you can have command line testing if you run run tests from the command line see “Custom testing with :extra-main-files”

on that testing docs page

if you run that from the command line you will see the test output on the command line whenever the code reloads

Is there a way to add my own CSS pre-processor but still tie in to Figwheel path watching?

That is, telling Figwheel to watch my SCSS files and when they change run my custom function, then push the new generated CSS files to the browser

You could have a separate process process watching scss files and writing to resources/public/css/style.css. When the scss files, the style compiler creates a new output css, which figwheel sees @orestis

Yeah, it’s just too .. many … watchers 🙂

@bhauman I was just adding support for figwheel main to JUXT's build tool (meaning edge will soon be upgrading too). I notice that cljsjs support was added ❤️.

@orestis with sidecar, I sovled this by using my own filewatcher. I think a potential solution here is a more "a la carte" figwheel, where there's a notify callback you can call on a whim, this should make it easier to integrate figwheel into other build tools.

@bhauman Am I setting myself up for bad things™ by having :watch-dirs point at directories which don't contain cljs? Or is that more of a "warning" than an "error"? Things seem to work okay.

They're all on the classpath (in fact, it's a list of directories on the classpath)

that is more of a warning

cljs will completely fail when you give it an empty src directory

to compile

unless that’s changed

@bhauman You mean in cljs.main, or cljs.build?

cljs.build.api/build

We've been passing that (mapv str classpath-dirs) up until now also, so I guess it's the same failure cases (that we haven't seen).

i’d have to look at the specific case again to get a handle on it

I just remember it was super ugly and there was no indication of what was wrong

🙈 I'm filling in defaults for people. It's probably okay, I always put stuff in "src".

Although, I have just noticed that this now causes figwheel to try and build all cljs on the classpath, which means that the injector I wrote which only works with sidecar is being compiled, which is failing the compile…

(mapv str classpath-dirs) is pretty intense

@bhauman it's pretty much my way of stopping a user from having to do anything.

I’m having an issue where, nearly as soon as it connects, the repl host page throws [goog.net.WebSocket] The WebSocket disconnected unexpectedly: undefined. The command-line repl then exits without error. Can anybody give me a hint on how to start troubleshooting this?

@toby962 do you have an alert blocking the page load?

@bhauman for deps.edn I can probably filter out a lot of things by parsing the clojure.libfile system property...

I started an empty project. Contains only the code from the tutorial and it still occurs.

are you using chrome, firefox?

I’ve tried both

are you on OSX?

I once saw Exception in thread "main" clojure.lang.ExceptionInfo: Eval timed out! fly by but just once.

OSX host, clojure docker container

oh

its probably just not connecting in the first place

I see the green banner for several seconds, if that counts.

…and a registered Figwheel session id

@toby962 it sounds like connectivity to the docker container

I’m assuming you are using a browser and that is connecting to the docker container

Possible. How do I prove it?

Correct assumption.

I’m not able to help you with that right now, unfortunately

fair enough

I take it a Figwheel session ID is given to the client before the websocket has finished connecting, then?

the client generates the session id

So, I’m correct that those messages are independent from the websocket negotiation going on?

…one thing that confuses me: why would the repl exit if the connection fails? shouldn’t it wait for another browser?