This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (9)
- # beginners (40)
- # boot (61)
- # cider (6)
- # cljsrn (5)
- # clojure (65)
- # clojure-gamedev (6)
- # clojure-greece (8)
- # clojure-ireland (1)
- # clojure-portugal (5)
- # clojure-russia (46)
- # clojure-uk (38)
- # clojurescript (177)
- # core-async (9)
- # cursive (17)
- # datomic (6)
- # dirac (8)
- # emacs (5)
- # error-message-catalog (8)
- # hoplon (248)
- # ldnclj (11)
- # ldnproclodo (1)
- # lein-figwheel (36)
- # leiningen (12)
- # mount (2)
- # off-topic (3)
- # om (26)
- # onyx (12)
- # perun (2)
- # planck (26)
- # re-frame (62)
- # reagent (55)
- # remote-jobs (2)
- # rethinkdb (1)
- # ring-swagger (14)
- # spacemacs (47)
- # untangled (69)
when listening to “goog.history.EventType/NAVIGATE” it doesn’t get triggered on fighweel reload, even though the listener is rebound, i’m assuming because the url hasn’t changed?
Is anybody using multiple builds with figwheel? I have a few builds with different definitions of the same namespace, and from time to time these definitions get mixed up: the compiled js for a certain build has (wrong) symbol definitions coming from another build. How can that happen? My builds have different target directories, so I would expect this could never happen. Of course I tried to run lein clean in between builds, but this does not solve the problem.
@stepugnetti: it sounds like you’ve got some wires crossing somewhere along the way. I’d suspect either your build definitions are reusing the same folder, or the HTML file you’re loading
@danielcompton: my builds have part of the code in common, but the part that differs is in different dirs, one for each build (though in files whose name is the same). And you are right: if I remove the source files of the other build, no problem occurs.
We do exactly the same, make sure
:asset-path are all unique for every build
Also, check that you don’t have
:source-paths set at the root of your
Yes all this is checked. And
:source-paths at the root was a problem before I removed it at the beginning of my project. Actually
:asset-paths is set only for one build, the only one using it (the other builds don’t output code for a web page but for an app, no html for them).
@stepugnetti: having namespaces that are the same in separate builds is not going to work
It's all in the same process and classpath resolution is probably going to get confused for sure
Actually it worked for me, most of the time. It’s just sometimes gets confused, without a clear reason. It usually starts with a compilation error (caused by me) in some source file. But the the confusion persists even after the compilation error has been resolved…
So, I should avoid having namespaces with the same name but different source file across different builds?
Well, my build fails even though it is the only one targeted by the only leiningen process running...
The other thing is that :source-paths from each build are all concatenated to the global source-paths and ultimately the classpath
It's a much bigger conversation. But you should think of namespace's as the identities that they are
I see. So I probably adopted the wrong solution for my aim. I wanted different implementations for the same symbol in different builds, so as to to write the core code only once and have it working differently in different builds.
As of now I put the definitions of this symbol in a
shared-symbols namespace that is defined in different files for different builds. But if cljsbuild or figwheel care more about the namespace name than the path of the file it’s defined in, this cannot work.
@stepugnetti: use closure-defines compiler option https://github.com/clojure/clojurescript/wiki/Compiler-Options#closure-defines