This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-09-06
Channels
- # 100-days-of-code (15)
- # beginners (32)
- # calva (2)
- # cider (37)
- # clara (1)
- # cljs-dev (47)
- # clojure (177)
- # clojure-boston (1)
- # clojure-dev (2)
- # clojure-germany (1)
- # clojure-greece (5)
- # clojure-italy (13)
- # clojure-nl (2)
- # clojure-sanfrancisco (1)
- # clojure-uk (72)
- # clojurescript (46)
- # cursive (20)
- # datascript (7)
- # datomic (14)
- # devcards (6)
- # docker (1)
- # duct (1)
- # emacs (1)
- # figwheel (3)
- # figwheel-main (151)
- # graphql (2)
- # hyperfiddle (1)
- # interop (3)
- # jobs (3)
- # lumo (2)
- # off-topic (21)
- # pedestal (1)
- # re-frame (9)
- # reagent (25)
- # shadow-cljs (57)
- # slack-help (4)
- # specter (21)
- # tools-deps (53)
- # vim (2)
@ghiden I recommend creating a wrapper function. (ns your.thing (:require ["react" :as react])) (defn create-element [...] (react/createElement ...))
you can also use (def create-element react/createElement)
if you don't care about the wrapping part
I am running into:
failed to require :target :browser-test for build :test
CompilerException: java.lang.RuntimeException: Unable to resolve symbol: defelem in this context, compiling:(hiccup/page.clj:20:1)
clojure.lang.Compiler.analyze (Compiler.java:6792)
clojure.lang.Compiler.analyze (Compiler.java:6729)
clojure.lang.Compiler$InvokeExpr.parse (Compiler.java:3813)
clojure.lang.Compiler.analyzeSeq (Compiler.java:7005) clojure.lang.Compiler.analyze (Compiler.java:6773)
clojure.lang.Compiler.analyze (Compiler.java:6729)
clojure.lang.Compiler.eval (Compiler.java:7066)
clojure.lang.Compiler.load (Compiler.java:7514)
clojure.lang.RT.loadResourceScript (RT.java:379)
clojure.lang.RT.loadResourceScript (RT.java:370)
clojure.lang.RT.load (RT.java:460)
clojure.lang.RT.load (RT.java:426)
clojure.core/load/fn--6548 (core.clj:6046)
clojure.core/load (core.clj:6045)
clojure.core/load (core.clj:6029)
clojure.core/load-one (core.clj:5848)
clojure.core/load-one (core.clj:5843)
clojure.core/load-lib/fn--6493 (core.clj:5888)
clojure.core/load-lib (core.clj:5887)
clojure.core/load-lib (core.clj:5868)
clojure.core/apply (core.clj:659)
clojure.core/load-libs (core.clj:5925)
clojure.core/load-libs (core.clj:5909)
clojure.core/apply (core.clj:659)
clojure.core/require (core.clj:5947)
clojure.core/require (core.clj:5947)
shadow.build.targets.browser-test/eval91055/loading--6434--auto----91056 (browser_test.clj:1)
shadow.build.targets.browser-test/eval91055 (browser_test.clj:1)
shadow.build.targets.browser-test/eval91055 (browser_test.clj:1)
clojure.lang.Compiler.eval (Compiler.java:7062)
clojure.lang.Compiler.eval (Compiler.java:7051)
clojure.lang.Compiler.load (Compiler.java:7514)
when trying to use browser-test, when I add hiccup it works again. So maybe you did some deps cleanup?@mitchelkuijpers there was a race-condition related to that. I fixed it a few versions ago though. which version are you on?
I delayed loading all the web stuff so that is a) doesn't get AOT compiled and b) doesn't delay server startup
but due to loading hiccup in a different thread you could end up trying to use it before it finished loading
I was trying out 2.6.6, but I just downgraded to 2.6.3
npx shadow-cljs watch test
It was fixed when I added hiccup to my deps
but as I said its a race condition so it is just a timing issue. if the build starts too fast you'll run into the problem again.
Ah ok, that makes sense
I am using tools.deps not sure if that helps
you misinterpret the error. hiccup is definitely on the classpath regardless of you adding it or not. it is not a dependecy problem.
its a race condition. shadow-cljs will load the hiccup
namespace in another thread but due to how Clojure works the namespace will be immediately available
the other thread has (:require [hiccup.core ...])
and clojure sees that the ns
is already loaded
the other thread continues on. wants to use defelem
but it isn't loaded yet and boom
Ah ok, thank you for the explanation
@basti what I do is to have a separate :node-script
target that requires all the test namespaces so that they are compiled. Not ideal I know, maybe @thheller has a better idea
@basti :node-test
disables all devtools since it supposed to exit after running the tests since we need the exit code for CI. is it not sufficient if you just use node-repl
and manually load whichever test you are working on/want to run?
Is node-repl
compiling everything on the classpath independently? I think that is the problem I have noticed
manually loading would work but it’s tedious because I have to load all test dependencies, and If I required a library in my tests that hasn’t been required yet it’s missing
so what @basti is saying is something I faced as well, and it basically made me do something like this in a separate entry point:
(ns my.registry.repl
(:require [cljs.spec.alpha :as s]
;; so that we have the test compiled in the REPL
[my.registry-test]
[my.registry.aws-test]
[my.registry.azure-test]))
yeah well explained @richiardiandrea! that’s what I was trying to say!
if node-repl
compiles everything independently from the entry point then it should be good
otherwise the REPL would complain and you have to require in the REPL the namespace in order to "compile" it the first time, that is what I have experienced at least
yes and that is what I think we are both asking, if there is a way to have a node repl that automagically requires/compiles the test namespaces - without the glue file above
but why do you need to require ALL? do you not use the REPL to work on ONE particular test/ns? why do the others need to be loaded?
this might be true, but still, maybe metadata marker on the ns that tells node-test
to preload that particular one ns would be convenient 😉
in the :browser-test
target, if I use a custom runner-ns do I need to :require
all of them test namespaces?
no. just modify https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/test/browser.cljs to your needs
was a change made to the type inference between 2.4.4 and 2.6.6? I'm running into https://dev.clojure.org/jira/browse/CLJS-1918 all of a sudden