figwheel not serving the app.js

[yogthos]

I'm updating the Reagent template and I ran into a problem where Figwheel 0.5.4 will not server the app.js file from target/cljsbuild/public/js/app.js. This works correctly in 0.5.3-2. Here's a sample project.clj file.

[bhauman]

looking at this now

[bhauman]

I traced this to your ring handler stack, your call to (resources "/") is not working and passing through to (not-found "Not Found"). When I comment that out it falls through and gets to my (resources "/" {:root "public"}) call which picks up the file. Soooo ...

[bhauman]

The :resource-paths and class path are all correct. I have no idea why your call to resources isn't working.

[bhauman]

actually think I may have found it

[yogthos]

good to hear, let me know if you want me to do more testing

[bhauman]

man actually this is super funky ... it works and then it doesn't work, think it may be something else in the ring stack because the Figwheel stack works on its own with compile targets in the "target". Maybe reloader is doing it I don't know.

[bhauman]

Yeah there is definitely something in your wrap-middleware that is messing with the state when I remove that . The figwheel-server ring stack hasn't changed at all in this release.

[yogthos]

Hmm, yeah that's pretty weird because it was working consistently with the last release. This is the only middleware being used too. It's just ring-defaults, wrap-exceptions, and wrap-reload.

[bhauman]

@yogthos you bumped up ring-defaults and ring at the same time you bumped up figwheel. I think the action is there.

[yogthos]

Yeah it does look like it's the interplay between them. Would make sense for Figwheel to work with the latest ring-defaults though. :)

[bhauman]

There is nothing fishy going on inside the Figwheel server.

https://github.com/bhauman/lein-figwheel/blob/master/sidecar/src/figwheel_sidecar/components/figwheel_server.clj#L156
This hasn't changed.

If you see a safer way to do it let me know.

[yogthos]

I'm still not sure what cause the issue in the new ring-defaults. Unfortunately, I haven't had much time to dig into this yet. I'll let you know if I figure it out though.

[bhauman]

I'm going to look at this again. It occurs to me that I can make this much simpler and get rid of the compojure dep. Which would be a good thing.

[yogthos]

Sweet! :)

[yogthos]

Awesome, I'll push out a new reagent-template with the latest

[yogthos]

I did a bit of testing with the latest and I still see the issue unfortunately. It doesn't appear to be related to middleware, I've tried just using the defroutes defined handler as :ring-handler and also failed to load Js.

However, this doesn't happen every time either. Is it possible that there's some race condition in loading the resource paths that's happening. The cljs build config is set as follows here.

{:main "{{name}}.dev"
              :asset-path "/js/out"
              :output-to "target/cljsbuild/public/js/app.js"
              :output-dir "target/cljsbuild/public/js/out"
              :source-map true
              :optimizations :none
              :pretty-print  true}

Not sure if that helps, but I'll keep looking to see if I can narrow this down.

[bhauman]

So you tested against the snapshot?

On Thu, Jun 16, 2016 at 12:16 AM, Dmitri Sotnikov [email protected]
wrote:

I did a bit of testing with the latest and I still see the issue
unfortunately. It doesn't appear to be related to middleware, I've tried
just using the defroutes defined handler as :ring-handler and also failed
to load Js.

However, this doesn't happen every time either. Is it possible that
there's some race condition in loading the resource paths that's happening.
The cljs build config is set as follows here
https://github.com/reagent-project/reagent-template/blob/5bf255cc6f82a4b9daf767d6d7fdbc079e5d0a1c/resources/leiningen/new/reagent/project.clj#L65
.

{:main "{{name}}.dev"
:asset-path "/js/out"
:output-to "target/cljsbuild/public/js/app.js"
:output-dir "target/cljsbuild/public/js/out"
:source-map true
:optimizations :none
:pretty-print true}

Not sure if that helps, but I'll keep looking to see if I can narrow this
down.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#428 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAAKQMbdpmY3dtj8VK-6DWxc4yoACGGJks5qMM4kgaJpZM4Iz01d
.

[bhauman]

I haven't deployed this change to clojars yet.

[yogthos]

Ah my bad, I saw a new version show up on Clojars after the issue getting closed and assumed it had the change. Just did a local install for the snapshot and can confirm everything is looking good. Sorry for the noise. ;)

[lvh]

I ran into a similar issue trying to do the same; although it's not clear that it's exactly the same thing yet, because I'm still seeing it with the current release, which does come after that commit.

[lvh]

I don't know if this is related, but, I'm seeing:

Figwheel template

Checkout your developer console.

... despite having configured a ring handler that doesn't show that page.

[lvh]

Downgrading to 0.5.3-2 does indeed resolve the issue.

[smogg]

Similar issue - ring handler no longer shows my page, but an index.html is displayed trying to load http://localhost:3449/js/compiled/reason.js

[lvh]

@smogg Can you add the exact versions where the problem started?

[smogg]

0.5.4-4 is the first versions where the problem appears

[lvh]

0.5.4-3 does not have the same issue? Have you been able to narrow this down to a commit?

[smogg]

No issues on 0-5.4-3. Not sure which commit introduced the issue exactly

[smee]

I used to have a similar problem. The reason was a transitive dependency in my class path with an "index.html" in the jar. Depending on the order of loading, this (wrong) index.html got loaded instead of the one provided by figwheel. As soon as I got rid of this dependency everything went back to working perfectly.

[smogg]

@smee Did it also triy to load reason.js? Do you happen to remember what dependency was that?

[smee]

See keechma/forms#2
Keechma/forms and lein-doo

[smogg]

@smee Yeah, it looks like that's it - one of the packages I'm using has index.html in public folder. Thanks!

[smogg]

So do I understand it correctly - now every package that has resources/public/index.html file will always override the handler in my app? That doesn't sound right imho

[smee]

Not always, no. It depends on the order of dependencies in your classpath / the loading order as implemented by the classloaders utilized. My understanding is, that if you just use the classloader to load resources from the classpath, you may experience the error you observed. The only two ways to prevent this are to avoid having other public/index.html files on your classpath or patch figwheel so it manually traverses all dependencies, identifies its own public/index.html and loads that (with special code to handle exploded/packaged cases...), not very feasible.

[lvh]

@smee Thanks, that was very insightful. Would it be helpful to short-circuit the index.html-manually-loading logic if a ring handler is provided? (My understanding is that that's how figwheel used to work.)