Fork me on GitHub
#shadow-cljs
<
2020-02-12
>
Ivan Koz02:02:27

how to disable eval loader mode, can't find it in the user guide, asking for educational purposes i need to turn evalLoad inlining off

Quest03:02:33

+ Made a plain react-native example with re-frame. Forked off thheller's reagent example. Might be handy to anyone wanting this stack without Expo. https://github.com/Quezion/re-frame-react-native

šŸ§ 8
šŸ‘ 12
thheller09:02:02

@nxtk :devtools {:loader-mode :script} in the build config

šŸ™ 4
thheller09:02:26

@royalaid yeah thats a problem. if I could go back in time I'd slightly change the namespacing system in CLJS since the nested stuff actually is causing more issues than it helps with but yeah its too late for that.

misha09:02:50

this is embarrassing, but I get

Compiling ...
Execution error (ClassNotFoundException) at jdk.internal.loader.BuiltinClassLoader/loadClass (BuiltinClassLoader.java:582).
com.google.common.collect.Streams
upon shadow-cljs compile app

thheller09:02:08

dependency conflict, most likely guava. commonly caused by datomic

misha09:02:44

I am using it with {:deps true}, and got it from the very beginning, while calling watch, but then it magically got fixed by calling compile once.

misha09:02:04

Then I npm installed firebase and it blew up again

misha09:02:51

is there something I can do to find the offender?

thheller09:02:40

for deps.edn I'm not sure, probably clj -Stree (remember to enable all aliases you might have)

misha09:02:41

plus, it sounds naive, but it is strange to me to see java dependency conflict by installing js lib

thheller10:02:12

which JS lib do you mean?

misha10:02:33

npm install --save firebase

thheller10:02:59

first time you mention firebase but it has nothing to do with this

thheller10:02:08

other than that it triggers a code path that was previously unused

thheller10:02:14

(ie. shadow-cljs processing the firebase JS)

thheller10:02:25

the dependency conflict was there before

misha10:02:47

mb unrelated question: what is the best practice to keep js and java(clj) deps separated in deps.edn when using shadow?

defa10:02:22

Iā€™m using two aliases :backend and :web with almost all deps defined within the alias (`:extra-deps`) and the source directories in :extra-paths. You can put common deps or shared sources in the top level :paths and :deps. In shadow-cljs.edn :

:deps {:aliases [:web]}
works for me and plays along nicely with Cursive IDE in IntelliJ IDEA. (hint: in cursive you need to enable your aliases in the deps panel).

thheller10:02:08

don't use deps.edn for CLJS ...

defa10:02:44

Is this a general advice? I separate clj and cljs via aliases in deps.edn and it works fine.

thheller11:02:49

so do you really separate them or do you have top-level :deps and then a :cljs alias on top that inherits all the CLJ deps?

defa11:02:49

Oh, while reading on you suggest the same. Sorry.

thheller11:02:16

most people have CLJ top-level deps and just :extra-deps for CLJS

thheller11:02:28

which leads to problems like the discussed

defa11:02:29

:deps []

defa11:02:03

So no global deps, only :extra-deps in the aliases.

šŸ‘ 4
thheller11:02:05

deps.edn is totally fine for CLJ/CLJS. you just have to sometimes sort out dependency conflicts

thheller11:02:15

I don't like doing that so I keep them separate and never have to worry about that

thheller11:02:53

but yeah deps.edn is "better" for some things like gitdeps or local paths

thheller11:02:11

so there are legit use-cases where it should be used

defa11:02:14

Main reason for me is that this seems to be the only way to use Cursive propperly.

thheller11:02:28

yeah that too unfortunately šŸ˜›

defa11:02:18

This way it is just convenience to have backend and frontend in one project and IDE workspace. Probably not of an issue when using emacs or vim.

thheller11:02:04

yeah I have created "fake" dependency project.clj file before that just included ALL dependencies but wasn't actually used for anything

thheller11:02:38

but that was before Cursive supported deps.edn šŸ˜‰

misha10:02:31

ok, an example: how do I depend on rum then?

misha10:02:36

(I am just trying to figure out how it might be connected, e.g. via clj*c* dep)

thheller10:02:41

:dependencies [[rum "whatever-version"]] in shadow-cljs.edn

thheller10:02:03

I told you how it is connected

thheller10:02:24

that class it can't find is from guava (which is a JVM library)

thheller10:02:36

which is used be the closure compiler AND datomic

misha10:02:44

will rum show up in clj deps too? e.g. "for server-side rendering". or should I dep it both in shadow and in deps.edn? as rum is cljc lib

thheller10:02:01

you can only use one. *MY* recommendation is to use shadow-cljs.edn to declare CLJS dependencies and then deps.edn or project.clj for CLJ. yes there may be some overlap and things declared in both but that is not an issue

misha10:02:20

thank you

thheller10:02:45

OR you can use deps.edn with a :cljs alias and a :clj alias with a common :shared one

thheller10:02:57

but that is a bit cumbersome to use and might not actually save you from such conflicts

misha10:02:34

so if I will not solve the dependency jvm conflict, but move all cljs deps to shadow.edn, and will not use {:deps true} - js compilation should work, right?

thheller10:02:41

you can solve it in deps.edn but you have to find the conflict and resolve it

thheller10:02:59

as I said before if you have datomic then that is the most likely cause

thheller10:02:35

but yes moving all your CLJS related dependencies to shadow-cljs will most likely resolve the issue

thheller10:02:01

unless you add the one that is causing the actual problem ... then you are back where you started

thheller10:02:20

I haven't used deps.edn in a while ... maybe there is some easy way to make it tell you about version conflicts

misha10:02:32

I dont have datomic there. it'd be nice to make js compilation and jvm dep conflict - 2 separate issues. so moving deps over to shadow.edn now

thheller10:02:11

I'd at least try running clj -Stree once and see which guava version you get and from what

thheller10:02:17

that'll probably be enough

thheller10:02:53

but yeah I recommend shadow-cljs.edn so you don't have to worry about that at all

misha10:02:11

ok, moving dependencies worked. so I can take care of conflict a bit later. Thank you again.

p-himik17:02:01

The example at https://github.com/highcharts/highcharts-react#example-with-custom-chart-component uses this:

import Highcharts from 'highcharts/highstock'
I can confirm that it's working at https://stackblitz.com/edit/react-4ded5d?file=index.js (at least, in Firefox). The table at https://shadow-cljs.github.io/docs/UsersGuide.html#_using_npm_packages says that anything that looks like import defaultExport from "module-name"; should be written as (:require ["module-name" :default defaultExport]). I required this:
["highcharts/highstock" :as Highcharts-as]
["highcharts/highstock" :default Highcharts-default]
In runtime, Highcharts-as is the desired object, and Highcharts-default is undefined. Any idea why is there a discrepancy for this particular module?

lilactown17:02:53

it depends on whether the JS lib that gets loaded is CJS or ESM

p-himik17:02:05

Do you think it makes sense to add a * to that table? Otherwise, it's not that clear that there are exceptions if you don't read further since the table appears like the ultimate authority.

thheller17:02:42

I don't know. many packages actually package code properly so that :default works even for CommonJS packages

thheller17:02:54

some don't ...

p-himik17:02:00

FWIW, I would add a * or some other indication that a user should read further about :default in particular. :) Seems like I'm not the only one that doesn't read/remember everything, given the question about Highcharts in #clojurescript