shadow-cljs 2024-04-12 | Slack Archive

hifumi12308:04:37

Does shadow-cljs support wildcards in package.json exports? I have a package with "./*.js": "./dist/src/*.js" but shadow is failing to resolve the relative import "./utils.js" I verified that ./dist/src/utils.js indeed exists, hence my question

thheller09:04:08

it does but thats not a valid wildcard. wildcard as far as I could tell from the non-existent spec are added as-is

thheller09:04:20

so ./utils.js becomes ./dist/src/utils.js.js

hifumi12309:04:00

Thanks! Modifying the exports helped resolved this error but now I need to deal with files that are being imported without file extensions at all. Thankfully this is an internal library, and this seems more like an issue with the library rather than shadow.

thheller09:04:45

could be that my implementation is totally wrong. I basically had to reverse engineer everything since the docs overall are more than lacking

thheller09:04:11

https://webpack.js.org/guides/package-exports/

thheller09:04:21

my interpretation was that * is only allowed at the end

thheller09:04:48

so "./*": "./dist/src/*.js" is valid but "./*.js": "./dist/src/*.js" is not

👍 1

pez12:04:16

I’m trying to run tests for my app with Karma as per https://shadow-cljs.github.io/docs/UsersGuide.html#target-karma. However, the app reads config from the html dom (which I provide in index.html) For Karma this fails, at least with the basic setup, since I don’t know how to give Karma the needed config in the dom. Anyone understand enough about what I am talking about to give me a pointer?

thheller12:04:19

when are you reading the config? seems like something you could do via fixtures?

thheller12:04:55

kinda hard to give more specific advice without knowing when you load the config or how it is actually used

pez13:04:26

I get the error even if I remove my tests for reading the config. But that’s probably because I have a def like so:

(def ^:private config
  (edn/read-string
   (.-textContent (js/document.getElementById "app-config"))))

I’ll try removing that and see if I get the runner working at all. But then I would like it to be able to run my config tests too.

thheller13:04:27

my suggestion would be the following

thheller13:04:30

(def config nil)

thheller13:04:39

then, assuming you have a :init-fn build config

thheller13:04:52

in that init fn you do (set! whatever-ns/config (edn/read-string ....))

thheller13:04:21

in the tests via fixtures you set it to whatever you want for the test

thheller13:04:34

never actually attempting to read it from anywhere of course

thheller13:04:57

might be possible to supply a html file for karma. I don't actually know, never used it

pez13:04:08

Of course, I don’t know. But maybe I do not need to test that the read works. 😃

pez13:04:38

I’ve tried a while now to supply a html file. Should be possible, but I’ve spent a bit too much time on it now and will go for not reading the config in the tests.

thheller13:04:41

test that edn/read-string works?

pez13:04:53

Test that my config reading setup works. But it is basically just edn/readstring from the dom so I can skip it. Was the first time I supply config this way so I think that’s why I added a test for it.

pez13:04:37

It now works. Thanks! Don’t think I have used set! like this before. But I’m used to it from JS. 😃

pez11:04:23

Actually, the set! approach didn’t quite work with the way I was using the config. But I found that Karma sets a thing on the window object so that I could do this:

(def config
  (if (exists? js/__karma__)
    {}
    (edn/read-string (.-textContent (js/document.getElementById "app-config")))))

2024-04-12

Channels