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.

nvm, fixed. Forcing route dispatch on init

@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

We have multiple builds running fine with Figwheel

@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 :output-to, and :output-dir, :asset-path are all unique for every build

Also, check that you don’t have :source-paths set at the root of your project.clj

Not totally sure if that will affect it, but we don’t have it there

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).

Thanks

Did you find the solution?

No. I just left for lunch Now I start again looking for a fix. Thanks!

@stepugnetti: having namespaces that are the same in separate builds is not going to work

This has to do with source resolution in closurescript compiler

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?

Only if you are going to compile them in the same process

Well, my build fails even though it is the only one targeted by the only leiningen process running...

Well there's a whole bunch going on here soil ...

I may have spoken too soon

This could happen because of corruption of a previous build process

But I run lein clean in between.

(and the target directory gets removed)

The other thing is that :source-paths from each build are all concatenated to the global source-paths and ultimately the classpath

Ahah! This could be a problem

And this is how sources are resolved that aren't in the build fileset

Do you know if there is a way to prevent leiningen from doing this?

This is not leiningen, its cljsbuild and figwheel that do this

And that behavior is probably not going to change anytime soon.

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

You can use it with a multi method and bobs your uncle