@mauricio.szabo no clue. it uses transit? maybe a transit version conflict or so?

@filipematossilva yeah that sounds impossible? its just a regular callback when the websocket disconnects? nothing what would defy the rules of single-threaded browser world? 😛 https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/cljs/devtools/client/websocket.cljs#L22-L24 https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/cljs/devtools/client/browser.cljs#L268-L270

is there a way to configure shadow to load scripts via script tag in dev? as it is done in “pure” cljs repl

:devtools {:loader-mode :script} for the initial page load. for the REPL itself no, that always uses eval.

got it

Does anyone has a good tailwind library in Clojure to recommend? (Usable on both clj and cljs)

what do you need a library for? I just have [:div {:class "px-4 py-2 md:px-6"}] etc?

Oki doki :) make sense, I wondered if anyone had something like styled components to compose them :)

@neo2551 this is a nice setup example for tailwind and shadow: https://github.com/jacekschae/shadow-cljs-tailwindcss

Thanks :)

Is there an easy way for git describe based version information derived at build time to be available as variable at runtime? I was thinking about using :closure-defines and #shadow/env together with a shell script… and was wondering if there is a more straight forward way? I’d like to have a git based version string to show in the app. The environment react-native. Android build.gradle and iOS Info.plist integration would be the icing on the cake but not mandatory 😉

is there any difference between shadow-cljs and clojurescript regarding handling externs-inference for stuff required from npm modules?

trying to reproduce an issue we’re experiencing since upgrading to shadow-cljs 2.14.0, where a bunch of new :infer-warnings popped up for code with js interop with npm modules. 2.13.0 can still correctly infer them and compile without those warnings

having this in package.json

"prosemirror-transform": "^1.2.8", "prosemirror-state": "1.3.3"

(ns foo
  (:require ["prosemirror-state"]))

(defn apply-tr [tr]
  (.getMeta tr nil))

2 |   (:require ["prosemirror-state"]))
   3 | 
   4 | (defn apply-tr [tr]
   5 |   (.getMeta tr nil))
---------^----------------------------------------------------------------------
 Cannot infer target type in expression (. tr getMeta nil)

@kommen 2.14 upgraded to CLJS release .866, not sure if there were any changes in CLJS regarding this. on the shadow-cljs side I didn't change anything regarding this (not intentionally at least)

ah no I did have to make one change. the code that gathers potential extern names from JS code had to remove one branch since the closure compiler folks changed something and removed an API I was using

that may affect that I guess. couldn't find any problem in my code but that doesn't do a whole lot of JS interop

ok, thanks for investigating! for our codebase this results in over 200 new warnings and breakage of the advanced build around them.

wow, did not expect that

let me see if I can revert that change or find the "replacement" API in gcc

technically it is closer to regular CLJS inference now, so maybe hints would an an alternative solution. the property extraction from npm JS code has always been sort of black magic voodoo 😛

type hints works for us, just was surprised to run into this. thus my initial question on the difference between cljs and shadow-cljs regarding this

yeah, shadow-cljs will process all npm code and in the process collect some properties. CLJS never looks at JS code so never collects those.

@kommen should be back to normal in 2.14.2

yep, looks good. CI with integration tests is green and the warnings are gone. will test more on monday. thank you so much!

I'm beginning to hate the closure compiler ... for some reason on windows it started rewriting the filenames I give it from some/thing.cljs to some\\thing.cljs. which wouldn't matter except that it breaks source maps and the build report. super fun time trying to figure out why and when that changed ... :face_vomiting: