Fork me on GitHub
#shadow-cljs
<
2022-12-12
>
indy20:12:40

Is there way to use npm git deps that has jsx code which gets automatically processed during import?

indy21:12:40

Never mind, my goal was for the most efficient way to import a UI component lib into my cljs app locally for dev. I read the docs and seems it isn’t possible. I’ll need to somehow manually process the files via babel (which I already do for some local jsx).

indy21:12:40

Never mind, my goal was for the most efficient way to import a UI component lib into my cljs app locally for dev. I read the docs and seems it isn’t possible. I’ll need to somehow manually process the files via babel (which I already do for some local jsx).

indy21:12:40

Does shadow-cljs cache files inside node_modules? I’m watching a build on a js lib that updates the package but the changes aren’t reflected on the cljs app. The js package is npm linked to the cljs app.

indy21:12:51

The changes are reflected when I restart shadow. Recompiling also doesn’t work.

indy22:12:44

I’m on the latest shadow 2.20.14

indy22:12:32

Tried adding to the build config but no luck.

:build-options
   {:cache-level :off}

fabrao22:12:57

Hello all, I'm trying to import like this

import Split from '@uiw/react-split'; -> ["@uiw/react-split$default" :as Split] ?
but this Splitis returning nil.

thheller05:12:18

> This table only applies if the code you are consuming is packaged as actual ES6+ code. If the code is packaged as CommonJS instead the $default may not apply. See the section below for more info.

thheller05:12:30

may just be ["@uiw/react-split" :as Split]

Aleed23:12:18

is it possible to specify not to parse deps when using :esm target with runtime :react-native ? My understanding was that traditional :react-native target would let metro process deps, but seems that the runtime does not behave that way I was seeing if it was possible to use shadow-cljs with expo-router, which requires integrating cljs into file-system routing which is why I’m using esm target

thheller05:12:45

but esm can't output files into different dirs, so this likely won't work for what you are trying to do

Aleed06:12:16

i was going to manually import them from the generated shadow-cljs files

thheller06:12:07

hmm maybe that works yeah

Aleed17:12:35

so using js-provider does work, resolving dependency issue but now when using import I’m seeing dist/cljs-runtime/cljs_env.js: dist/cljs-runtime/cljs_env.js:Invalid call at line 1394: import(x.startsWith("./") ? "." + x : x) full line referenced above

globalThis.shadow_esm_import = function(x) { return import(x.startsWith("./") ? "." + x : x); }
not sure why it’s an invalid call

Aleed17:12:13

i think you’ve said in past that shadow-cljs does not play well with nextjs-like FS routing. but it does seem to be way JS is headed, as expo’s new router uses FS as well. with esm target do you think it’s more feasible? I was excited about Cherry providing better interop with JS ecosystem, but also recently learned about esm target in shadow-cljs, which servers similar purpose. One distinction may be that in Cherry cljs logic is imported in shared in npm package, but other than I imagine behavior is similar

thheller17:12:43

sorry I haven't looked at next or any other JS platforms in many years

thheller17:12:51

so I don't know what things look like nowadays

thheller17:12:34

not sure why the import fails, looks fine to me

thheller17:12:26

esm could be adjusted to generate all kinds of files in theory

thheller17:12:44

but as I said before the fs based routing thing just doesn't map to CLJS well at all

thheller17:12:08

so you are probably better off writing the "route" files yourself in JS, and then just importing the CLJS code from there

Aleed18:12:19

Yeah that’s what I intended to do, at least to start i guess you mean it’s not an ideal experience, not that it’s not tenable

Aleed18:12:12

ah ok, regarding import issue dynamic es6 imports are not supported in metro https://github.com/facebook/metro/issues/52