Fork me on GitHub
#shadow-cljs
<
2019-07-18
>
superstructor02:07:10

re-frame-10x has a bug when using shadow-cljs whereby require like [react-highlight.js :as react-highlightjs] leads to an exception due to not binding the correct value, whereas ["react-highlight.js" :default react-highlightjs] does work. As a library, I will need to maintain support for both standard CLJS/figwheel and shadow-cljs with any fix. Any guidance on how one supports both please ?

thheller07:07:03

@superstructor the problem is with how the CLJSJS package is created. it is basically doing the "unwrapping" of the default export. https://github.com/cljsjs/packages/blob/master/react-highlight/resources/main.js

thheller07:07:48

that should be module.export = Highlight; and re-frame-10x should be using [react-highlight.js :as react-highlightjs] and then later when using it react-highlightjs/default in the adapt-class call

thheller07:07:10

otherwise I can't think of a quick way to make this work both ways

thheller07:07:08

or alternatively just the typical cljsjs alias namespace with global variable. like most other packages

thheller07:07:32

the problem is just that it is using the react-highlight.js ns which maps directly to the npm package

thheller07:07:57

and the variable it exports does not match what you get when you require the package directly because of its Highlight.default unwrapping

superstructor08:07:49

Thanks for the comprehensive investigation and help @thheller! The issue is clear now. I'll think about the most pragmatic solution.

thheller08:07:33

@superstructor just thought of a much simpler solution

thheller08:07:13

in re-frame-10x when using the react-highlightjs you could just use (or react-highlights/default react-hightlightjs)

thheller08:07:46

so shadow-cljs would use the /default but the rest would use the other one

thheller08:07:00

no need to change other dependencies or so that way

Marcin08:07:56

@thheller I have a problem referencing JS file from JS file from CLJS. Any JS referenced from CLJS works fine, but got different errors when I import another file here. An example

Marcin08:07:39

export in this scaler looks like this export const scaleImage = () ....

Marcin08:07:16

It worked the first time the compilation went through. After some changes (and the reload) it stopped working

thheller08:07:16

hmm dunno. you can try deleting the .shadow-cljs/builds dir and restarting the build

thheller08:07:23

maybe some bad cache in the conversion code?

thheller08:07:33

looks like it should work

Marcin09:07:22

ok, trying. Cheers!

Marcin09:07:29

works! Thank you!

Marcin07:07:59

@thheller it happens every now and then when the hotreload hits after touching (nested) imported js file - then I need to delete builds folder from shadow-cljs and it starts to working again. It’s quite easy to reproduce it: - call JS file from CLJS - call JS file methods from the above JS file (as an import)

Marcin07:07:00

workaround for me here is to pass callbacks or partially run functions in promises from CLJS, but it doesn’t seem to be a solution

thheller08:07:36

do you have an actual reproducible example?

superstructor14:07:27

@thheller Hah thanks 🙂 :thumbsup: I also thought to go down this route.

superstructor15:07:38

I released re-frame-10x 0.4.2 that fixes compatibility with shadow-cljs as per above. Thanks @thheller!

👍 4
mss18:07:14

in the process of formatting a project as a monorepo using modules each with a deps.edn + shadow-cljs.edn. shadow is installed globally via yarn. I moved everything over in a way that I thought was correct but now when running shadow-cljs compile my-app I’m getting an error:

Could not locate shadow/cljs/devtools/cli__init.class, shadow/cljs/devtools/cli.clj or shadow/cljs/devtools/cli.cljc on classpath.
when I explicitly add shadow to my deps.edn, this goes away. confused why that might be the case, as it wasn’t listed in my deps.edn pre monorepo migration

thheller19:07:00

@mss you must add shadow-cljs to your deps.edn as of the latest version

👍 4