shadow-cljs

https://github.com/thheller/shadow-cljs | https://github.com/sponsors/thheller | https://www.patreon.com/thheller
thheller 2021-05-28T06:52:55.237500Z

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

thheller 2021-05-28T06:53:37.238300Z

@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

2021-05-28T10:45:00.240200Z

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

thheller 2021-05-28T10:45:39.240500Z

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

2021-05-28T10:46:16.240800Z

got it

2021-05-28T11:02:45.241300Z

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

thheller 2021-05-28T11:04:09.242200Z

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

2021-05-28T13:13:23.244600Z

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

wilkerlucio 2021-05-28T13:40:54.245300Z

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

2021-05-28T13:42:09.245600Z

Thanks :)

defa 2021-05-28T15:15:38.251100Z

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 😉

knubie 2021-05-28T15:29:46.251200Z

@defa You could maybe write a macro for that.

knubie 2021-05-28T15:30:20.251400Z

the macro would run git describe from clojure at build time and you could include that information in the expanded code

kommen 2021-05-28T15:52:40.253800Z

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

kommen 2021-05-28T15:56:24.256500Z

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

kommen 2021-05-28T16:46:29.258700Z

having this in package.json

"prosemirror-transform": "^1.2.8", "prosemirror-state": "1.3.3"
this
(ns foo
  (:require ["prosemirror-state"]))

(defn apply-tr [tr]
  (.getMeta tr nil))
compiles without a warning with 2.13.0, but produces this warning with 2.14.0
2 |   (:require ["prosemirror-state"]))
   3 | 
   4 | (defn apply-tr [tr]
   5 |   (.getMeta tr nil))
---------^----------------------------------------------------------------------
 Cannot infer target type in expression (. tr getMeta nil)

thheller 2021-05-28T17:25:36.258800Z

https://github.com/day8/shadow-git-inject

thheller 2021-05-28T17:27:11.259900Z

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

thheller 2021-05-28T17:28:33.260900Z

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

thheller 2021-05-28T17:28:58.261400Z

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

kommen 2021-05-28T17:34:11.263900Z

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

thheller 2021-05-28T17:34:29.264200Z

wow, did not expect that

thheller 2021-05-28T17:35:13.265Z

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

thheller 2021-05-28T17:38:44.266500Z

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 😛

kommen 2021-05-28T17:46:21.267800Z

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

thheller 2021-05-28T17:50:42.268600Z

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.

👍 1
thheller 2021-05-28T19:02:33.269100Z

@kommen should be back to normal in 2.14.2

kommen 2021-05-28T19:34:40.270200Z

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

👍 1
kommen 2021-05-31T13:11:02.292400Z

@thheller fyi, we have it in production now it looks good so far

👍 1
thheller 2021-05-28T19:50:07.271900Z

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:

🥶 2
rberger 2021-05-29T17:11:09.279300Z

Is it a closure compiler problem or a Windows problem? Windows’ original sin was using backslash instead of slash for file separators IMHO.