Fork me on GitHub
#shadow-cljs
<
2021-09-01
>
cjmurphy03:09:12

Is a :closure-defines value in shadow-cljs.edn able to be dynamic? By that I mean if I change it and force compile (or not) should the runtime pick up the change? I know these goog-define vars are compile time, but as there's continuous compilation with shadow-cljs I hoped I could change a value on the fly while developing (leaving it strictly at its default when not). I've got one that doesn't seem to be dynamic at the moment, but I'll try harder if I know they can be...

cjmurphy03:09:36

It is dynamic, but I have to refresh the page rather than force compile.

javahippie12:09:31

When building my reagent-sources with shadow-cljs, I am seeing this warning that I don’t understand. r/atom is used in many places, but only this one occurrence is marked and I cannot get the warning to go away. Is this a bug or am I just not able to see the error?

thheller13:09:12

@javahippie thats odd indeed. I assume you have proper (:require [reagent.core :as r]) in your ns?

javahippie13:09:25

Yes, that’s the whole :require

thheller14:09:13

that is extremely odd indeed. especially given that it only warns after the third use

thheller14:09:32

can you check if there is maybe a hidden unicode character in the line?

thheller14:09:56

sometimes they end up in there making an a not an actual a or so

thheller14:09:12

try typing that line again and just deleting the existing

🙏 2
javahippie14:09:42

Ah, that was exactly the issue, thanks a lot!

thheller14:09:17

gotta love computers 😛

martinklepsch13:09:04

Since 2.15.5 the following command is producing an error

npx shadow-cljs -A:build:test compile test --config-merge '{:autorun false}'
Error building classpath. Specified aliases are undeclared: [:-A]
It doesn’t quite make sense to me since it looks like the aliases aren’t passed at all. Was there any change in shadow that could cause this?

thheller13:09:46

are you sure you didn't upgrade clojure tools.deps recently?

thheller13:09:55

I mean that error is from clojure not shadow-cljs?

thheller13:09:18

whats the full log?

thheller13:09:26

it should tell you which command it runs?

martinklepsch14:09:31

It does appear to download a lot of dependencies but I’m not seeing a log that shows the clojure invocation

thheller14:09:21

ah thought it would log that. it'll run clojure -A:build:test -M -m shadow.cljs.devtools.cli watch app (for shadow-cljs watch app)

thheller14:09:37

does that work when you run it? unsure what else would be happening? there only was an unrelated change in the npm script recently?

Drew Verlee17:09:01

import LogRocket from 'logrocket'; would translate to (:require ["logrocket" :default LogRocket]) correct?

borkdude17:09:10

@drewverlee nowadays you can also use ["logrocket$default" :as logrocket]

thheller17:09:35

all depends on what the package is actually published as 😛

Drew Verlee17:09:49

reading and ty.

currentoor19:09:21

Has anyone run into this error?

Must use import to load ES Module: /Users/toor/mutesync/shells/electron/node_modules/node-fetch/src/index.js
require() of ES modules is not supported.

borkdude19:09:58

Yes, that seems familiar (wink wink @dnolen @thheller )

borkdude19:09:44

@currentoor This is how to do it with nbb:

npm install -g nbb
npm install node-fetch
fetch.cljs:
(ns fetch
  (:require ["node-fetch$default" :as fetch]))

(-> (fetch "")
    (.then #(.text %))
    (.then prn))
nbb fetch.cljs
And this should be similar when using shadow-cljs with :esm target

currentoor19:09:21

thank you @U04V15CAJ, what is nbb?

currentoor20:09:18

i don’t see this technique documented in the shadow-cljs dev guide

currentoor20:09:38

is it a temporary workaround or a standard API?

borkdude20:09:57

The :esm target is currently undocumented. This is how you can use it: https://gist.github.com/borkdude/7e548f06fbefeb210f3fcf14eef019e0

borkdude20:09:28

You could also look at how nbb itself is built, it uses the same build target