Fork me on GitHub
Garrett Hopper02:04:24

@richiardiandrea I assume you were trying to (:require ["fs"]) from within your ns? Is fs a built-in node module? Perhaps you weren't building with :target :nodejs?


Yes I think I was doing it right, it might not be. In any case I opened a Jira wish repro

Garrett Hopper03:04:23

Shouldn't code split definitions be in relation to :asset-path? I think I might be having an issue with symbolic links (from Boot); my module definitions in cljs_base.js refer to a full path to my Boot cache. This results in cljs.loader trying to load that full path from the server instead of just from :asset-path. Any ideas?


@dnolen I'm interested in getting this one fixed for the next release: I did some work on this locally, but it's not working reliably. I would appreciate some guidance or help on it. Ping me when you have some time to discuss. I add a bit more details to the issue.

Garrett Hopper15:04:47

So apparently if :output-to in :modules isn't a sub-directory of :output-dir, the module's load path (by cljs.loader) ends up being the entire path. The workaround is easy, but I assumed I could set :output-dir to a thowaway cache directory and get my module outputs in the location I want. Is this be design?


Can it be GCC's behavior? Never explored, for sure it would be good to write this in the README

Garrett Hopper16:04:37

Perhaps. I'll need to dig into it more later. For now I'll build everything in a single directory and copy the artifacts out.

Garrett Hopper19:04:00

Do I need to do anything special with functions that are going to be resolved after cljs.loader/load? The (resolve 'namespace/function) generated different code when it's being called versus when I'm just trying to log it. Neither is successfully resolved possibly due to names being munged. Strangely when I'm trying to call the resolved function, the generated output contains the full path to the .cljs file. Why is that?

Garrett Hopper19:04:19

Also, I shouldn't need to (cljs.loader/set-loaded! :cljs-base), should I? If I don't, there's an xhr request for it even though it's already been loaded by the index.html.

Garrett Hopper19:04:01

Duh... :optimizations :advanced was eliding the function I was trying to resolve? What's the workaround for this? At the moment I've just made the module I'm loading call the init function itself without any resolving necessary.


I wonder if we have a bug in resolve. For example, this properly returns nil in the Clojure REPL

(resolve '


But throws in ClojureScript, when it should arguably also return nil. The root cause is that it macroexpands to involve a call (exists? which throws.


if it's fully qualified, it throws


(when the lib hasn't been loaded)


Yes. I suppose that fits its intended use within the scope of cljs.loader stuff.

Garrett Hopper21:04:34

It took me forever to figure it out, but apparently cljs.analyzer can't be loaded via cljs.loader from a split. It needs to be in :cljs-base. Does that sound right?


Hrm. Are you doing some self-hosted stuff?

Garrett Hopper21:04:45

Nope, I just happend to have a split that used cljs-http which required read-string from cljs.analyzer. I was very confused when I realized that requiring clojure.pprint in another split turned the issue on and off.

Garrett Hopper21:04:29

Adding cljs.analyzer to [:modules :cljs-base :entires] was an easy fix. I was just surprised.

Garrett Hopper21:04:14

Also figuring out that I actually had to clear cache and hard reload (right click on reload button in Chrome) each time instead of my habitual Ctrl + Shift + R to make sure the xhr requested split wasn't cached took a while to figure out.


Are you adding a new feature to the way cljs.loader works? (I haven't been following the backlog closely.)

Garrett Hopper22:04:49

No, this is just the standard cljs.loader.