This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-06-01
Channels
- # aleph (2)
- # beginners (137)
- # boot (4)
- # cider (10)
- # clara (29)
- # cljs-dev (71)
- # cljsrn (7)
- # clojure (105)
- # clojure-bangladesh (1)
- # clojure-france (2)
- # clojure-italy (4)
- # clojure-nl (3)
- # clojure-russia (1)
- # clojure-spec (30)
- # clojure-sweden (5)
- # clojure-uk (71)
- # clojurescript (217)
- # cursive (36)
- # data-science (1)
- # datomic (11)
- # duct (53)
- # fulcro (2)
- # garden (3)
- # jobs (1)
- # lein-figwheel (23)
- # luminus (3)
- # lumo (7)
- # mount (13)
- # off-topic (88)
- # pedestal (3)
- # re-frame (63)
- # reagent (85)
- # remote-jobs (1)
- # ring-swagger (3)
- # shadow-cljs (81)
- # spacemacs (5)
- # tools-deps (16)
- # yada (2)
@symfrog probably something simple since that’s exactly a case it’s supposed to handle
@thheller thanks! That successfully reproduces it. The issue does not occur when setting the clojurescript dependency to 1.9.946 in deps.edn, so this seems to be a 1.10.238 (and master) issue. Do you know what about your example triggers the issue?
@dnolen The issue seems to cause an invocation of a function across module boundaries to fail at runtime when :advanced compilation is used, which means that :modules and :advanced compilation can effectively not be used together in 1.10.238 in conditions that trigger the issue? Should I open a Jira issue for this now that a minimal repro is available?
@symfrog yes please, just copy the contents of the repro into the ticket though - don’t link out
Issue is now available here: https://dev.clojure.org/jira/browse/CLJS-2763
I’ve compiled the thing and I cannot understand what the problem is or what I should be looking for
@mfikes trying to reproduce 2763 also seems to show that the git caching stuff seems broken
if you try to build that repro you get a out/cljs_deps.js
file with relative paths to cache directory - that can’t be right
@dnolen OK. I'll probably be able to look into it sometime over the next week. (If urgent, perhaps we could revert the git deps feature.)
@symfrog yep, I’m not convinced about your problem and I think @thheller thing is something different
@symfrog re: your problem I would no longer follow your lines of speculation. metadata doesn’t matter, what’s in the compiler environment also doesn’t matter
there was a bug around a exists?
now resolved on master - but I honestly don’t see how this applies to your issue
@dnolen I have added the problematic output for 1.10.238 to the issue as well as the correct output from 1.9.946. It is related to line 7 of out/demo/a.js
where the metadata is incorrect when compiled with 1.10.238. I am not sure that this is the ultimate cause of my issues, but I am sure that the metadata is being set incorrectly by cljs.core/resolve
due to the defs of demo.foo.b
not being populated in cljs.env/*compiler*
at the time of the compilation of demo.a
.
so to understand what we should be looking for need to step back and understand what resolve
actually does
later when you invoke var that JS reference will hopefully to point to a thing that exists
all this stuff about metadata and compiler info is completely irrelevant for invoking across module boundaries
if some JS property foo.bar.baz
exists when you deref the var, invoke across the module boundary will work
as to why it worked before and not now, that will probably lead us to the real problem
but we need a real minimal reproducer, now that the previous one turned out to be an unrelated thing
and the hypothesized causes reported on the ticket so far aren’t relevant as far I can see
@dnolen thanks, it helps that I can focus elsewhere then to find the cause for my actual problem, but since I noticed the metadata issue I thought I would chase that down first. I would say there are potentially 2 issues then, the metadata issue (confirmed) and whatever is causing my actual problem.
the only way for you to have an issue is A) Closure believes that demo.foo.b.bar
doesn’t exist
The module is loaded, and works with 1.9.946. I will continue digging and see if I can find the actual cause now that the metadata issue is confirmed not to be the cause.
@dnolen master fails to compile om.next
(beta 3) with the error Caused by: clojure.lang.ExceptionInfo: clojure.lang.PersistentList cannot be cast to clojure.lang.Named at line 2525 om/next.cljc {:file "om/next.cljc", :line 2525, :column 33, :tag :cljs/analysis-error}
@dnolen thanks, Sablono now fails to compile for the same reason: https://github.com/r0man/sablono/blob/master/src/sablono/interpreter.cljc#L87
@dnolen thanks! It compiles now, but I still have the same problem, will keep digging.
ok, will keep it in mind, must be A since the callback of cljs.loader/load
is invoked and I can resolve the produced js variables from the console. I have also run the compiler with additional log output to check that the ns is built.
@dnolen on my actual project I get Uncaught TypeError: Cannot read property '$cljs$core$IFn$_invoke$arity$2$' of null
at runtime when invoking ((resolve 'target.module.ns/init) arg1 arg2)
in the callback of cljs.loader/load
. Everything works fine when I use :simple optimization, only breaks with :advanced. I will do the same for the minimal repro and add the outcome to the ticket.