@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 😉
@defa You could maybe write a macro for that.
the macro would run git describe
from clojure at build time and you could include that information in the expanded code
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-warning
s 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"
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)
@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!
@thheller fyi, we have it in production now it looks good so far
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:
Is it a closure compiler problem or a Windows problem? Windows’ original sin was using backslash instead of slash for file separators IMHO.