Clojurians Log v2

@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

@thheller I haven’t prepared an example yet, but it seems I have found workaround for my issue by adding js file with next content

(function () {
  goog.global.shadow$modules = {infos: {test: null}, uris: {test: []}}
  shadow.loader.init("");
})();

still don't know why you need that but looks fine

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

@thheller https://github.com/Valdermeyder/karma-modules-support/tree/master I have created a small but enough to reproduce example

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

well yeah but that is missing the entire context? I mean why do you call the loadable in the test in the first place? is that rendering actual UI code or what are you doing?

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

I am not calling it in the first place. It is called by the function which is tested. I understand you concern that in this example it looks like a first call but in my real case it is one of the things which happen. In general the context is when user have certain permissions call this method from another module. It was split by modules to load this additional code only for users which have this certain permission. I’ll not argue that it is the best solution which can be implemented but it is already done and I’m not in charge to change it right now.

Anyway I think the problem of running karma tests when modules and lazy load are used is not related to the context. As you can see it fails even in very simple example.

(ns my.app-spec
  (:require
    [cljs.test :as ct :refer [deftest is]]
    [shadow.loader :as sl]
    [<http://my.app|my.app> :as app]
    [my.core]))

(ct/use-fixtures :once
  (fn [test]
    (sl/init "")
    (test)))

I'm really unsure how to treat loader related things in tests. since it can't actually load a module the test using it becomes kind of pointless

The example above will work only once, the next test suite will fail at least from what I saw in the code.

yeah, it is probably hard to achieve fully but when your require lazy loadable namespace in the test (e.g. my.core), lazy loader works fine, so I think here is only a matter of not failing :karma target when modules are used

I am not big fun of mocks but probably with-redefs can be used somehow to stub parts of the lazy loaded namespaces in case we don’t want to require them explicitly

@thheller are you okay to open issue in GitHub for that case?

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

sure

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

Thanks :)

https://github.com/thheller/shadow-cljs/issues/889

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

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

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