I was using bidi and couldn’t get middleware to work properly. (I assume because calling wrap-mw on the output of bidi’s make-handler can’t actually compose, but I didn’t test this.)
In any case, I reverted manually to Compojure, and everything seems fine (I need to integration test my API POST routes to see if the multipart-params middleware applied.), but now it’s 404-ing on the compiled JS application file. I have to assume that the dev-target directory isn’t properly being included in the Ring (resources “/”) search path, given that CSS files are found properly.
I have to also assume this is specific to me because I reverted manually from bidi, and this works properly for fresh invocations of Chestnut with Compojure.
I can at least assure you that Dev-target isn’t supposed to be part of your resources. Lots of history with cljc files being recompiled in cljs land causing issues with reloaded.repl - if the compiled cljs files are in the class path clj reloading gets super confused.
Not sure I’m able to tell you what’s wrong without some kind of repro though…
The Chestnut template for ./dev/user.clj defines dev-system by overriding the :middleware key, which assumes that the :handler component was included in the system by using something named :middleware.
In my middleware reorganization (the whole thing which led me to abandon bidi for Compojure), I only did endpoint-specific middleware and dispensed entirely with site-wide middleware. Therefore the dev-system:handler didn’t have a reference to the extended :middleware with [wrap-file "dev-target"] in it.
As an additional point, because dev-system fetches the site-wide middleware from the config on the :middleware key, you have to make sure to maintain site-wide middleware in the config and nowhere else, otherwise dev-system will drop them. (Incidentally, this explains why I couldn’t nest maps under the :middleware key in the config.)