Fork me on GitHub

@thheller I was thinking a bit more about the approach in 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.


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

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


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


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.


who didn't find cljs sources? metro shouldn't care, it should only see the sources generated in that dir


I mean the original CLJS for source-mapping during debugging


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


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


source maps otherwise are self contained and contain all sources


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?


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


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


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


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


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


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


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


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


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


you can't hack the cljs parts that way


those are precompiled and only the finished JS files is used


well that explains it šŸ˜„


thanks for the help šŸ™‚


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


yeah that is what i'm going to do


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


that is already supported?


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


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


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


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


that would be the support for generic JS objects


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


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


really nice way to do that


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


ahh that's awesome. very useful for custom objects


really useful for react/other components

Ryan Jerue17:05:08

Hello @thheller looking at this guy It looks like that this means that

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


no, there is no separate setting for node_modules source maps


hmm kinda accidental that this works then I guess


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?