This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # 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
fs a built-in node module? Perhaps you weren't building with
Yes I think I was doing it right, it might not be. In any case I opened a Jira wish repro
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
: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
(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
: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
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
cljs.analyzer. I was very confused when I realized that requiring
clojure.pprint in another split turned the issue on and off.
[: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.)