Fork me on GitHub
#shadow-cljs
<
2021-05-03
>
mbertheau07:05:15

@thheller I was thinking a bit more about the approach in https://github.com/thheller/reagent-react-native with react-native/metro separated into a subdirectory. You specifically said "CLJS tooling related things" go in the top-level package.json. Is it accurate that that conflicts a bit with the default behaviour {:npm-deps {:install true}} which installs non-tooling JS deps in the top-level package.json / node_modules, instead of the one in react-native/, where metro in the end looks for it? One might end up with different versions of the same package in the two node_modules directories.

thheller08:05:17

that is correct yes. I'll likely remove the automatic :npm-deps install completely at some point and make it a proper manual command instead

šŸ’Æ 3
thheller08:05:18

but the duplicate install won't be used under normal circumstances so it doesn't matter too much for now

thheller08:05:23

also you don't have to do this separation. it just made sense to me. I also don't actually use react-native for anything so I might be totally wrong

mbertheau11:05:54

I like the separation very much, I was delighted when I found that example! There's so many files in a react-native project, all on the top level, that just come straight from the react native template. I like a cleaner workspace. Thanks! Then I'll set {:npm-deps {:install false}} and go with that one right away. I briefly tried debugging though and it didn't find the CLJS source. I suspect that that has to do with the fact that the CLJS source files are outside of the metro / react native root, but I didn't have time yet to look into that.

thheller11:05:31

who didn't find cljs sources? metro shouldn't care, it should only see the sources generated in that dir https://github.com/thheller/reagent-react-native/blob/master/shadow-cljs.edn#L14

mbertheau11:05:01

I mean the original CLJS for source-mapping during debugging

mbertheau11:05:33

But as I said, I just stumbled over this and haven't had a moment to confirm or disprove that shallow hypothesis

thheller11:05:42

does react-native finally support source maps? been a while since I checked

thheller11:05:58

source maps otherwise are self contained and contain all sources

Fabim13:05:13

My app is surprisingly large in release mode. I used shadow-cljs release app on my reagent/reframe app. the js folder that is created is 25MB. do I need to manually delete the cljs-runtime folder?

mbertheau14:05:36

@merklefabian try deleting the output folder before doing release app. Most of the big stuff in there is only needed for the development build.

thheller14:05:35

the cljs-runtime folder is not used by release builds yes

Fabim15:05:38

Thanks for your quick answer. Whats the reason it is not deleted automatically?

thheller15:05:23

shadow-cljs doesn't delete stuff as sort of a rule šŸ˜›

chrisetheridge17:05:28

is it still possible to 'hack' on shadow-cljs by adding the lib to the classpath? i've added it to src/ and i get conflicts on compile so i assume it is being added to the cp. unfortunately i don't see changes i've made to the codebase, or see any hot reloads when i change cljs files

thheller17:05:10

@biscuitpants I'm not sure I understand the question. what did you add to src? replacing shadow-cljs internal namespace should be fine yes?

thheller17:05:40

if you are using shadow-cljs.edn only (no deps.edn, project.clj) you might need to add :aot false to the top level

chrisetheridge17:05:25

yeah i've got src/shadow/cljs/ui/components/inspect.cljs and just added a simple prn to ui-tap-panel and it doesn't seem to be overwriting the default inpsect.cljs

chrisetheridge17:05:38

i'm using shadow-cljs.edn with deps.edn and :deps true

thheller17:05:53

you can't hack the cljs parts that way

thheller17:05:19

those are precompiled and only the finished JS files is used

chrisetheridge17:05:44

well that explains it šŸ˜„

chrisetheridge17:05:01

thanks for the help šŸ™‚

thheller17:05:03

you can compile the UI code locally and replace it for your app if you want

chrisetheridge17:05:12

yeah that is what i'm going to do

chrisetheridge17:05:34

fwiw i'm trying to add js/Object support to inspect

thheller17:05:50

that is already supported?

chrisetheridge17:05:25

hmm i'll double check my versions, but doing tap> on a pure JS object just printed js/Object

thheller17:05:33

for that you don't need to change the UI code at all btw

thheller17:05:50

since that part is handled by the code that is injected into your app

chrisetheridge17:05:17

ah. i'll dig more through the code then. definitely missed something

thheller17:05:37

that would be the support for generic JS objects

thheller17:05:09

you can extend the Datafiable protocol onto any objects in your codebase and it'll just work in the UI

chrisetheridge17:05:03

ahhh that is much easier! i did not know that. thank you

chrisetheridge17:05:06

really nice way to do that

thheller17:05:50

can be handy to be able to look into "foreign" objects via the UI

chrisetheridge17:05:40

ahh that's awesome. very useful for custom objects

chrisetheridge17:05:03

really useful for react/other components

Ryan Jerue17:05:08

Hello @thheller looking at this guy https://github.com/thheller/shadow-cljs/issues/434#issuecomment-461206429 It looks like that this means that

:js-options
{:source-map false}
would prevent source maps from things inside of node_modules from being outputted?

thheller17:05:21

no, there is no separate setting for node_modules source maps

thheller18:05:49

hmm kinda accidental that this works then I guess

zhuxun223:05:02

Is there an easy way to "re-export" a variable from a js libary using the same name? For example, instead of having to say:

(ns xxx
   (:require ["my-lib/my-thing-1" :default my-thing-1*]))

(def my-thing-1 my-thing-1*)
for every my-thing-n, is there a way similar to (:require ["my-lib/my-thing-1" :default my-thing-1* :reexport), so that I can use xxx/my-thing-1 in another ns in the same project?