Fork me on GitHub
#shadow-cljs
<
2019-09-27
>
jmmk01:09:11

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

thheller07:09:14

shadow-cljs never compiles .clj files? it only loads them when they are used as macros?

thheller07:09:51

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

thheller07:09:44

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.

jmmk13:09:54

@thheller I figured out what it was: user.clj is picked up by shadow-cljs, and mine included other .clj files

thheller13:09:52

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

dpsutton03:09:55

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?

thheller07:09:23

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

thheller07:09:39

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

thheller07:09:53

doesn't have to be a proxy so I should probably adjust those docs a bit šŸ˜›

dpsutton04:09:05

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

thheller07:09:18

not sure what this might be about? maybe just load ordering? ie. the tasks.list ns not properly requiring re-frame.std.?

vinurs06:09:02

the 2.8.58 version show this when auto reload

thheller07:09:41

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

vinurs07:09:01

shadowcljs

thheller07:09:40

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

thheller07:09:59

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

thheller07:09:06

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

thheller07:09:16

so something else must be triggering that load?

vinurs07:09:08

i found that i enable the react-native autoload

vinurs07:09:16

hot-reloading

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

thheller13:09:09

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

thheller13:09:41

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

thheller13:09:45

code splitting doesn't allow that

Daniel Leong14:09:20

Nope, itā€™s totally isolated. Iā€™m converting an existing project from leiningen

thheller14:09:10

it doesn't have to be a direct require

thheller14:09:24

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

thheller14:09:31

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

thheller14:09:57

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?

thheller14:09:44

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

thheller14:09:29

(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

thheller14:09:17

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

thheller14:09:43

upgrade specter?

thheller14:09:49

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

thheller14:09:06

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!

isak19:09:37

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

thheller19:09:36

@isak you can turn off specific warnings via :compiler-options {:warnings {:that-type false}}

thheller19:09:53

but its still spam that should be fixed

thheller19:09:09

whats the point of warnings if everybody ignores them

isak19:09:59

@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

isak19:09:02

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.

dpsutton19:09:56

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

isak19:09:07

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?

thheller19:09:27

well in the case of java or so you don't actually have the source so you aren't compiling that

thheller20:09:04

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

thheller20:09:20

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

thheller20:09:31

just like lein clean is the default fix all

thheller20:09:46

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

thheller20:09:56

and some of them are probably ok and can be ignored

isak20:09:41

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

isak20:09:55

yea, you are right. Maybe it is hard to have a good solution as long as that is the case with CLJS.

thheller20:09:17

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

thheller20:09:36

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

8
thheller20:09:17

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

dpsutton20:09:15

attempting to switch from figwheel to shadow revealed quite a few warnings in our code and bidi

rafaeldelboni21:09:37

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

thheller21:09:09

@rafaeldelboni oh. pushed 2.8.59 to npm. forgot to push again. npm was failing when I tried pushing last time