Fork me on GitHub

On, 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


it is picked up by clojure, shadow-cljs can't do anything about that


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?


you can configure :devtools {:devtools-url ""} in the build config


that should make it connect to unless you enable SSL in shadow-cljs?


doesn't have to be a proxy so I should probably adjust those docs a bit 😛


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.?


the 2.8.58 version show this when auto reload


@haiyuan.vinurs auto reload done by react-native/expo or shadow-cljs?




but only the second part of the error message is from CLJS


Requiring module "build/index.js", which threw an exception:


this part is not from the hot-reload in shadow-cljs


so something else must be triggering that load?


i found that i enable the react-native autoload



Daniel Leong13:09:39

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.


so (:require [wish.worker.core ....]) somewhere


code splitting doesn't allow that

Daniel Leong14:09:20

Nope, it’s totally isolated. I’m converting an existing project from leiningen


it doesn't have to be a direct require


could be ns.a -> ns.b -> wish.worker.core


something in the chain somewhere requires it

Daniel Leong14:09:41

Could doing something at the repl cause it? My tooling uses load-file and such

Daniel Leong14:09:54

☁  wish [dhleong/shadow-cljs] ag wish.worker.core
44:                          :worker {:entries [wish.worker.core]

136:     :compiler     {:main                 wish.worker.core
146:     :compiler     {:main                 wish.worker.core

1:(ns wish.worker.core
It’s not required anywhere


REPL could cause this yes but not when it is happening right when the build is first started

Daniel Leong14:09:47

Okay, sorry I should have clarified. A fresh server stop/start resolves it, it just occurs sometimes if I’m working on the worker

Daniel Leong14:09:44

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])


(probably. don't actually know)

Daniel Leong14:09:22

Hmm alright good to know, thanks. Hopefully I can figure out what my tooling is doing and avoid that

Daniel Leong14:09:22

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

Daniel Leong14:09:44

Awesome. Thanks!

Daniel Leong14:09:24

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


upgrade specter?


hmm it might not actually be fixed yet. can't tell


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

Daniel Leong14:09:03

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}}


but its still spam that should be fixed


whats the point of warnings if everybody ignores them


@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.


I imagine go has similar things? Consuming does as source versus artifact I suppose


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


if anyone has suggestions I'm totally willing to change stuff


but I also know if I add the option to ignore warnings thats the first thing people will enable by default


just like lein clean is the default fix all


warnings are also kinda weird in CLJS since some of them should definitely be errors


and some of them are probably ok and can be ignored


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.


well the best path is to fix the warnings. they are there for a reason after all.


problem is that normal CLJS doesn't warn in some cases. doesn't mean the code is correct just nobody knows.


and since only shadow-cljs warns people often don't seem to care much


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