This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-06-18
Channels
- # aws (21)
- # babashka (32)
- # babashka-sci-dev (3)
- # beginners (17)
- # biff (1)
- # calva (8)
- # clj-kondo (1)
- # cljfx (8)
- # cljs-dev (3)
- # clojure (13)
- # clojure-belgium (1)
- # clojure-europe (16)
- # clojure-losangeles (2)
- # clojure-norway (6)
- # clojurescript (11)
- # conjure (1)
- # data-science (1)
- # fulcro (2)
- # gratitude (5)
- # helix (1)
- # joyride (3)
- # malli (14)
- # nbb (4)
- # off-topic (11)
- # other-languages (10)
- # polylith (4)
- # re-frame (2)
- # sci (3)
- # shadow-cljs (20)
- # spacemacs (3)
- # tools-deps (1)
- # vim (4)
Working on adding shadow-cljs to a project, and when I open a REPL after adding shadow-cljs
to the deps, it's complaining about not being able to find cider/piggieback
, (a requirement of our REPL entry point function). shadow-cljs
also has a dependency on cider/piggieback
, but it's the same version, so I can't see why that would make a difference.
Maybe this is a question for #clojure though?
For hot loading on reloading dependent namespaces: https://code.thheller.com/blog/shadow-cljs/2019/08/25/hot-reload-in-clojurescript.html#:~:text=If%20example.app%20wasn%E2%80%99t%20automatically%20recompiled%20together%20with%20example.util%20you%20would%20not%20get%20a%20proper%20warning%20that%20example.util/foo%20no%20longer%20exist. It seems in either the case the warning will not show because the way namespace reloading does not remove existing definitions.
Sorry, was that in response to me? I don't think that's related because it's not a ClojureScript REPL where I'm encountering the issue.
Anyway, fixed my issue by increasing the ClojureScript version.
@i the blog post is referring to the compiler warning get. the runtime environment is irrelevant for that, but yes existing definitions in the runtime are not removed. the next sentence even mentions that?
it recompiles the dependent namespaces for the potential warnings yes. as explained in the blog post
I was saying the only benefit of loading dependent namespace is for the warning. I cannot see other benefits.
and yes, that is only done for the warnings. no other reason. but compiling produces the warnings. not loading them.
Ah. I didn’t know it. Turns out only the modified namespace will be loaded. Extra question, since the dependent namespace is not changed. So when compiling again on it, how will do with the compiled output, just ignore it?
"not changed" is a kind of difficult subject to figure out. so it is loaded along with the modified namespace
> compiling dependent namespaces. not loading. So the dependent namespace was loaded eventually? I thought you were saying its only compiled but not loaded (evaluated) at all.