I am getting an exit status 0 for a test build with :autorun set to true that has failing tests. This does not seem like the expected exit status.

Hi. Looking at the manifest.edn, I see both cljsjs/react.js & node_modules/react is this expected ?

@claudiu yes. in shadow-cljs cljsjs.react is just a "bridge" to the npm react. see https://github.com/thheller/shadow-cljsjs/blob/master/src/main/cljsjs/react.cljs

only required because some libs still use cljsjs.react instead of react directly. it does not include the actual cljsjs code ever

@kenny :autorun is mostly meant for watch and therefore cannot emit an exit code. you are probably better off running tests manually instead

@wilkerlucio possible yes. when running karma in watch mode however it will destroy the REPL on each reload

ahh cool 🙂 thank you. Trying to see if I can get the bundle size down a bit, after adding semantic-ui to my project 🙂

I would appreciate some feedback on https://github.com/thheller/shadow-cljs/issues/292

@thheller I opened an issue about the Tether library: https://github.com/thheller/shadow-cljs/issues/294 do you think you can help me with that? that's my last blocker to make a first shadow try release here

can check in a few minutes, just finishing up another thing

thank you 🙂

> We at HubSpot have been thrilled by Tether's success! However, the demands of maintaining such a complex project have outstripped our willingness and ability to do so effectively, as a quick glance at the issue tracker will tell you.

that does not inspire confidence in the library 😉

yeah, just more of the legacy stuff I have to keep around for a while

it's not the worst, I can just copy their dist file, fix and use it directly (removing the second definition fixes it)

@wilkerlucio unfortunately there is no way to turn that error into a warning or off

no problem, thanks for looking it, I'll just use my own copy, this should not need upgrade as far as I see

Hi, I'm trying to use https://github.com/ccampbell/mousetrap and all is fine, I was even able to use plugins by writing (:require ["mousetrap/plugins/global-bind/mousetrap-global-bind"]). I wonder - is it the correct usage in a scenario where a library developer just wants you to include a <script> tag on your page? It appears to be working, with and without .js extension.

@p-himik not sure I understand the <script> question? the .js is optional and doesn't affect the output whether you use it or not

@thheller The documentation at https://github.com/ccampbell/mousetrap/tree/master/plugins specifies that if I'm to use a plugin, I have to write something like <script src="%path-to-plugin.js%"></script> in my HTML. And I guess the above :require does just the same, with no potential problems?

hmm the plugins rely on the Mousetrap global and don't properly express their dependency on mousetrap itself but if it works it works

just make sure you always require mousetrap before any of the plugins

@thheller just curious, the deps from shadow-cljsjs, they are looked up at runtime, or they go bundled with shadow?

just pushed 2.3.35 with some perf improvements. please let me know if things actually got faster and not slower 😉

shadow-cljs just depends on it https://github.com/thheller/shadow-cljs/blob/master/project.clj#L66

@wilkerlucio 2.3.35 includes your updates

cool, thanks 🙂

hello folks, I am build some code, and I get a bunch of warnings:

[:init-store-fn] Compiling ...
Failed reading cache for cljs.core: com.fasterxml.jackson.core.io.JsonEOFException: Unexpected end-of-input: expected close marker for Array (start marker at [Source: java.io.FileInputStream@4359431f; line: 1, column: 1897496])
 at [Source: java.io.FileInputStream@4359431f; line: 1, column: 1900558]
Failed reading cache for cljs.spec.gen.alpha: com.fasterxml.jackson.core.io.JsonEOFException: Unexpected end-of-input: expected close marker for Array (start marker at [Source: java.io.FileInputStream@1702c0a8; line: 1, column: 135365])
 at [Source: java.io.FileInputStream@1702c0a8; line: 1, column: 176495]
Failed reading cache for cljs.core.async.impl.ioc-helpers: com.fasterxml.jackson.core.io.JsonEOFException: Unexpected end-of-input: expected close marker for Array (start marker at [Source: java.io.FileInputStream@63b0ad37; line: 1, column: 58113])
 at [Source: java.io.FileInputStream@63b0ad37; line: 1, column: 60267]
Failed reading cache for clojure.set: com.fasterxml.jackson.core.io.JsonEOFException: Unexpected end-of-input: expected close marker for Array (start marker at [Source: java.io.FileInputStream@3bf4621d; line: 1, column: 63470])
 at [Source: java.io.FileInputStream@3bf4621d; line: 1, column: 70979]
[:init-store-fn] Build completed. (69 files, 28 compiled, 0 warnings, 12.15s)
Done in 28.05s.

is it something I am doing wrong?

@richiardiandrea just a wild guess, are you declaring clojurescript dep in your dependencies (or maybe some dep is)?

I tend to have those weird errors when something sets cljs to a version that's different from the one shadow is using

I do

oh

which version it is? latest shadow uses 1.10.238 if I remember right

yes same version there

I was also specifying clojure 1.10-alpha4 maybe that is why

sounds a good place to try

will get rid of them

@richiardiandrea wild guess but maybe 2 instances of shadow-cljs are running and messing with each other?

clojure/clojurescript deps should not be factors there

something is messing with the transit json output of the cache

seems faster:

[:app] Build completed. (741 files, 615 compiled, 1 warnings, 31.53s)
[:app] Build completed. (743 files, 617 compiled, 0 warnings, 27.73s)

first line was 2.3.30, second is 2.3.35

using deps.edn for what is worth... so not sure about caching, or how to debug the problem

old vs new?

@richiardiandrea did you ensure that only one instance is running?

not a leftover one in the background or so?

dunno, I actually now cannot reproduce...

did it again on the exact same code base:

2.3.30: [:app] Build completed. (743 files, 617 compiled, 0 warnings, 31.35s)
2.3.35: [:app] Build completed. (743 files, 617 compiled, 0 warnings, 27.73s)

strange world of caching 😄

more than 10% improvement. that’s pretty good!

watch recompiles should be faster too

hm for some reason i had cache off. i don’t remember why i did that

oh. i bet it was when i didn’t realize that the code doesn’t reload when there are warnings.

well now i’m not sure about that data. i turned the cache on, redid the watch, the time went up to 51.19s. but on a restart it went down the 8.62s. maybe because it takes time to write the cache?

(note: I don’t use the server. i just run the watch directly because i only have one build)

watch starts a server so you are using the server

and yes enabling the cache will make it slower the first time since it has to be written

that makes sense. obviously that’s a good tradeoff.