This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (65)
- # boot (24)
- # cider (2)
- # clara (13)
- # cljs-dev (45)
- # clojure (48)
- # clojure-dusseldorf (2)
- # clojure-italy (69)
- # clojure-norway (1)
- # clojure-russia (5)
- # clojure-sanfrancisco (1)
- # clojure-spec (51)
- # clojure-uk (34)
- # clojurescript (312)
- # cursive (5)
- # datavis (1)
- # datomic (9)
- # duct (13)
- # editors (3)
- # emacs (2)
- # fulcro (11)
- # graphql (19)
- # hoplon (1)
- # immutant (2)
- # jobs (7)
- # jobs-discuss (38)
- # lein-figwheel (1)
- # luminus (6)
- # off-topic (2)
- # parinfer (10)
- # pedestal (1)
- # re-frame (9)
- # reagent (28)
- # reitit (1)
- # remote-jobs (12)
- # ring-swagger (26)
- # shadow-cljs (232)
- # slack-help (8)
- # tools-deps (29)
- # unrepl (29)
- # vim (10)
- # yada (31)
@ghopper I fixed two things in master 1) build can now take 1 argument, just opts 2) you were right, there was still a bad bug, the orphan stuff was quite wrong - try your failing example with master w/ the method you were using earlier when you get a chance
@ghopper note it’s important to understand if you have an orphan that will lead to worse splits
you really don’t want things to end up in base, so in this case
(cljs.build.api/build opts) is better than
(cljs.build/api src opts)
cljs.main you don’t have to think about this since
cljs.main isn’t file system oriented wrt. namespaces to find to compile
@dnolen Someone mentioned on #clojurescript that infer-externs doesn't work together with
:global-exports and with quick testing I think it does't work
Yeah. If I understand inference correctly, it happens on
analyze-dot and obviously that won't be used with global-exports as there is no dot interop forms.
Not huge problem, global-exports are probably mostly used together with externs anyway. I'll open issue about this.
after having a wild ride with code splitting yesterday as well, the current master seems to work fine again. thanks for fixing this. my last remaining problem is that sometimes the module info in cljs.loader becomes empty. but this might be a figwheel problem.
calling the cljs build api after this happend fixes this. maybe figwheel need to compile cljs.loader after a reload as well.
it happens when I evaluate a file that references cljs.loader. since :recompile-dependents is true by default I think figwheel recompiles loader again but without cljs.core/MODULE_URIS and 'cljs.core/MODULE_INFOS set properly
I spent about 5–10 minutes discussing side-effecting macros and
:closure-defines in the Virtual Clojure Meetup talk, so perhaps that will help a little with preparation for the shared AOT cache feature.
@dnolen I looked a bit around in figwheel and piggieback, but could not find anything suspicious. I don't know too much about the cljs repl, but I wonder if we need a special case there to handle cljs.loader as well. any idea?
if you change the dependency graph during REPL interactions then probably we do need a special case
Actually that’s probably not an issue. We just need to recompile cljs.loader as we do in build from
yes, I think. was investigating but run over this: https://dev.clojure.org/jira/browse/CLJS-2679
I think the transport protocol changed from EDN to JSON recently, but the browser repl still reads EDN?
with this patch I can get the code splitting guide working again. before the browser repl was failing for me
david, can you point me to the code where you think we should handle the cljs.loader in the repl?
@dnolen That makes sense. In this case the orphan was part of
cljs-time, and I'm using
boot-cljs to build.
@dnolen I can't reproduce the issue with just
-e. The most minimal example I have so far is the example of the code splitting guide. The JIRA has the steps to reproduce.