This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-09-27
Channels
- # beginners (86)
- # calva (1)
- # cider (21)
- # clj-kondo (2)
- # clojure (31)
- # clojure-europe (3)
- # clojure-italy (7)
- # clojure-nl (7)
- # clojure-spec (15)
- # clojure-uk (70)
- # clojurescript (4)
- # clojutre (31)
- # code-reviews (6)
- # cursive (10)
- # datomic (8)
- # duct (3)
- # emacs (2)
- # fulcro (34)
- # funcool (3)
- # jackdaw (2)
- # jobs (10)
- # jvm (2)
- # kaocha (1)
- # off-topic (21)
- # pathom (11)
- # re-frame (10)
- # reagent (4)
- # schema (1)
- # shadow-cljs (72)
- # sql (1)
- # tools-deps (3)
- # vim (9)
- # xtdb (4)
On https://shadow-cljs.github.io/docs/UsersGuide.html, it states
> It is not recommended to separate source files by extension (eg. src/clj, src/cljs, src/cljc). For some reason this is widely used in CLJS project templates but it just makes things harder to use.
But as soon as I did this, shadow-cljs started trying to compile my .clj
and failed due to different dependencies under different profiles. What's the advantage of not splitting them? Why does splitting "make things harder to use"?
shadow-cljs never compiles .clj files? it only loads them when they are used as macros?
"harder to use" is subjective of course but macros tend to become annoying IMHO. they are written as .clj
files yet are meant for CLJS. so do you put them in src/clj
or src/cljs
or src/cljc
?
you can of course split things into src/frontend
src/backend
or whatever. I just don't like splitting by file extension. feels pointless IMHO.
@thheller I figured out what it was: user.clj
is picked up by shadow-cljs
, and mine included other .clj
files
at work we serve our product through figwheel and some custom networking setup so its ssl and a local domain. however figwheel's websocket happily goes over
. I'm having trouble setting up a similar situation with shadow. Is this possible?
seems you can't specify a different host for the ws. also hitting a lot of errors like failed to load aclaimant.dashboard_v2.pages.tasks.list.js TypeError: re_frame.std_interceptors.fx_handler__GT_interceptor is not a function
not sure what this might be about? maybe just load ordering? ie. the tasks.list ns not properly requiring re-frame.std.?
@haiyuan.vinurs auto reload done by react-native/expo or shadow-cljs?
In what situation would shadow-cljs give this error?
Module Entry "wish.worker.core" was moved out of module ":worker".
It was moved to ":app" and used by #{:app :worker}.
@dhleong88 you likely specified wish.worker.core
and the entry for the :worker
module. But something from the :app
module also did a direct require for wish.worker.core
.
Nope, itās totally isolated. Iām converting an existing project from leiningen
Could doing something at the repl cause it? My tooling uses load-file
and such
ā wish [dhleong/shadow-cljs] ag wish.worker.core
shadow-cljs.edn
44: :worker {:entries [wish.worker.core]
project.clj
136: :compiler {:main wish.worker.core
146: :compiler {:main wish.worker.core
src/cljs-worker/wish/worker/core.cljs
1:(ns wish.worker.core
Itās not required anywhereREPL could cause this yes but not when it is happening right when the build is first started
Okay, sorry I should have clarified. A fresh server stop/start resolves it, it just occurs sometimes if Iām working on the worker
How might I avoid creating this association? Is the only way to clean it up when made restarting the server?
this would happen if you are in say in your main ns (in-ns 'wish.main)
and then do (require '[wish.worker.core :as x])
Hmm alright good to know, thanks. Hopefully I can figure out what my tooling is doing and avoid that
Hereās an unrelated proposal: how would you feel about some mechanism to ask the client to try to reconnect to the server? I see in the code that you donāt want to auto-reconnect because the server config may have changed, but for example if I just close my laptop lid I get disconnected; the server is still running and I know it hasnāt changed, but right now I still have to reload the page to reconnect
you can probably just call shadow.cljs.devtools.client.browser.ws_connect();
in the browser console
Awesome. Thanks!
Okay last one (sorry for the barrage): is there a way to suppress warnings from dependencies? specter
, for example, produces:
------ WARNING #2 - :undeclared-var --------------------------------------------
Resource: com/rpl/specter.cljc:1275:19
Use of undeclared Var com.rpl.specter/java
--------------------------------------------------------------------------------
------ WARNING #3 - :undeclared-var --------------------------------------------
Resource: com/rpl/specter.cljc:1288:19
Use of undeclared Var com.rpl.specter/java
--------------------------------------------------------------------------------
there is no way to suppress those warnings. don't actually want to do that since it actually produces bad code that should be fixed
Alright, I suppose thatās fair. Thanks again!
@thheller What about if it is just something like 'you're shadowing uuid from clojure.core'? The problem is even if it is bad practice/bad code/whatever, the person using the dependency may not be in a good position to get it fixed, and then this behavior is just training them to ignore all warnings, because it is 90% spam from dependencies.
@isak you can turn off specific warnings via :compiler-options {:warnings {:that-type false}}
@thheller ok, good to know. I agree it should be fixed, but if the person reading the warning is powerless to do so, it seems like there'd be a lot of cases where it is not worth seeing every time
In most static languages I've tried, you never see compilation warnings triggered by your dependencies. It seems to be kind of a default with dynamic languages, seems pretty strange to me.
You're probably right, though it might be kind of a special case, because doesn't it do stuff like refuse to compile if you have an unused import?
well in the case of java or so you don't actually have the source so you aren't compiling that
but I also know if I add the option to ignore warnings thats the first thing people will enable by default
warnings are also kinda weird in CLJS since some of them should definitely be errors
For java, you could call it an implementation detail, no? I mean if compiling .java files as as fast as reading the .class files, I don't expect people would normally care what happened under the hood. Though if that switch were made I don't think they would cheer about getting warned about "your dependency foo has an unused variable in this file", for example
yea, you are right. Maybe it is hard to have a good solution as long as that is the case with CLJS.
problem is that normal CLJS doesn't warn in some cases. doesn't mean the code is correct just nobody knows.
attempting to switch from figwheel to shadow revealed quite a few warnings in our code and bidi
Is normal the npm / clojar versions being different? Right now we have 2.8.58 / 2.8.59, Iām trying to use the new prepl support
@rafaeldelboni oh. pushed 2.8.59 to npm. forgot to push again. npm was failing when I tried pushing last time
Thanks!