This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-04-14
Channels
- # beginners (53)
- # cider (10)
- # cljs-dev (23)
- # cljsrn (25)
- # clojure (68)
- # clojure-italy (4)
- # clojure-spec (25)
- # clojure-uk (7)
- # clojurebridge-ams (1)
- # clojurescript (10)
- # cursive (20)
- # datomic (21)
- # duct (4)
- # fulcro (1)
- # graphql (4)
- # hoplon (1)
- # java (7)
- # luminus (9)
- # off-topic (111)
- # om-next (2)
- # onyx (14)
- # re-frame (3)
- # reagent (9)
- # shadow-cljs (182)
- # test-check (32)
- # tools-deps (53)
- # uncomplicate (1)
- # vim (94)
- # yada (2)
@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
:thumbsup:
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: https://dev.clojure.org/jira/browse/CLJS-2682 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.
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
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.
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?
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
.
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 'clojure.zip/up)
But throws in ClojureScript, when it should arguably also return nil
. The root cause is that it macroexpands to involve a call (exists? clojure.zip/up)
which throws.
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?
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.
Adding cljs.analyzer
to [:modules :cljs-base :entires]
was an easy fix. I was just surprised.
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.)
No, this is just the standard cljs.loader
.