This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-08-07
Channels
- # announcements (10)
- # babashka (39)
- # beginners (230)
- # calva (16)
- # cider (20)
- # clara (4)
- # cljs-dev (16)
- # clojure (35)
- # clojure-europe (8)
- # clojure-filipino (5)
- # clojure-france (1)
- # clojure-nl (6)
- # clojure-uk (9)
- # clojuredesign-podcast (1)
- # clojurescript (55)
- # clojurewerkz (1)
- # core-async (13)
- # cursive (1)
- # data-science (1)
- # datomic (4)
- # events (1)
- # fulcro (26)
- # jobs-discuss (1)
- # kaocha (3)
- # malli (53)
- # observability (9)
- # off-topic (1)
- # project-updates (1)
- # re-frame (15)
- # reagent (1)
- # reitit (11)
- # rum (8)
- # sci (29)
- # shadow-cljs (7)
- # vim (12)
- # xtdb (13)
From the docs:
> Sometimes you will see examples of import Foo from “something” when the code is actually CommonJS code.
Just ran into this case recently.
However, it looks like if I try to require ... :as
after I incorrectly use require ... :default
, the require ... :as
fails and doesn’t do anything. I had to restart the shadow-cljs watch
process and reconnect to get it to work.
Is this worth documenting as a gotcha? Spent quite a lot of time debugging, because I thought the CommonJS import was failing as well.
@jysandy hmm yeah thats an issue. the problem is that the first :default
will create the DayPicker
binding. :as
is only taken if there is no other binding by that name since its normally reserved as a namespace alias. not really something I can easily fix. Just use :as
first and you won't run into this issue

trying to spin up shadow in cider for the first time in a while and getting the following, any ideas? > Exception in thread “main” java.lang.RuntimeException: Unable to resolve symbol: requiring-resolve in this context, compiling:(shadow/cljs/devtools/cli.clj:70:16)