@jeaye just tried out your repo and was able to repro the problem TimeoutError: transforming /Users/pe/prg/react-native-packager-bug/index.android.js took longer than 301 seconds.

Hi @pesterhazy, @jeaye: I just caught myself up on the #cljsrn chat history for the last couple of days, and the timing of this is pretty funny. I used to experience the same type of timeout/memory issues that you have been talking about, but I made some terrible hacks to avoid them when I was on RN 0.40.0. Last week I went through the upgrade process from RN 0.40.0 -> 0.46.4 process for the ClojureScript + React Native app that I work on, which (as expected...) broke my release bundling process again. So, after upgrading my hacky setup, I wrote a rough post (http://austinbirch.co.uk/2017/07/28/clojurescript-and-react-native-bundling-for-release-with-advanced-optimisations.html) about how I hacked my way around the issues for future reference, and mostly finished it up last weekend. I’ve published it in its current state just now in case there’s anything useful in there that can save you time/validate assumptions etc. @pesterhazy, I think your re-natal-husk idea is much much better than the setup I have, but you still might have trouble getting source maps working with it? If so, you might want to take a look at the first part of my approach (custom transfomer); it might help you to come up with something workable for source maps. I really wish I had had waited until this week to start upgrading RN so that I could have started with your approach - it seems pretty promising to me.

@austinbirch very interesting thanks

will read the blog post later today. good point about the source maps. Out of curiosity, what do you need the source maps for in Release builds?

on the larger point, I think we really need to break this cycle of packager updates breaking prod builds, again and again

ideally the fix should go into metro-bundler directly, but I'm not holding my breath given hoe reponsive their devs have been in the past

the 2nd best option would be a reliable workaround, which I think the react-native-husk experiment might prove to be

hello, how would one go about implementing deep linking in clojure, as in: https://medium.com/react-native-training/deep-linking-your-react-native-app-d87c39a1ad5e

@pesterhazy > Out of curiosity, what do you need the source maps for in Release builds? We had some trouble using :simple optimizations. The final main.jsbundle was massive (we have quite a large project, I suppose) so the app did take a long time to start in release. We were also were getting some iOS OOM issues too. Oh, and builds created with :advanced seemed more responsive UI-wise for us too. Compiling with :advanced optimisations solved those problems (much smaller bundle, less time taken for RN to load it, no OOM issues), but meant that any exceptions that occured during use were pretty annoying to debug. The stacktraces sent to Sentry listed columns/lines from main.jsbundle, and obviously all of the names were mangled & minified too. Recovering source maps gives us original file+line+column in Sentry, and inline original-CLJS for the context around those stack traces as well. Agree with the rest of what you’ve said above. I was hoping that as other users of compile-to-JS languages had issues the packager would grow to be able to work with that model, but that doesn’t seem to have happened yet. I did consider figuring out a PR for metro-bundler, but without any documentation it’s pretty hard to understand.

I’m continuing to dig into why NativeModules is empty for iOS, unless debugging remotely with Chrome. I found that it is also empty when doing prod builds, which seems to exclude the re-natal Figwheel bridging from being a cause. I’ll share if I figure out what is causing this.

@mfikes I'm pretty sure I've used NativeModules from re-natal in both figwheel and prod builds

@pesterhazy Cool. Perhaps something regressed with later RN versions

Could it be that it's a magical object that only works right of you access a property but you can't enumerate keys?

Maybe

Maybe the module was there all along but hidden

@pesterhazy You appear to be correct on the “magical object” theory.

Hidden in plain sight

I’ve updated the README showing things working now: https://github.com/mfikes/use-native-code

Thank-you @pesterhazy !

@mfikes no problem

What would be the standard way to handle different api urls when in dev vs prod for cljs? I’m fairly newer to front end so I’m not sure if this is even the right question.

the RN packager sets the js/__DEV__ var

I use

(defn dev? [] (and (exists? js/__DEV__) js/__DEV__))

so if you're compiling a bundle for Release configuration (xcode/iOS), (dev?) will be false, and true in Debug configurations

There's also :closure-defines {"goog.DEBUG" false} in your project.clj

note that you can nicely run Release builds in the simulator: run-ios --configuration Release

@austinbirch just had a chance to read your blog, nice work

@pesterhazy thanks. Still want to clear some of it up (usefulness is understanding why the packager tweaks are needed, not the implementation) but hopefully it won't be relevant for much longer!

@jeaye I've stolen your code generator: https://github.com/pesterhazy/re-natal-husk/blob/master/src/quax/lots.cljs

I've also simplified the transformation step: https://github.com/pesterhazy/re-natal-husk/blob/master/husk-react-native-xcode.sh#L103

@pesterhazy hehe, what a silly macro.

silly but useful 🙂

the husk approach seems to work for me, but it would be great if someone else could try it as well

I still have 2 todos

it'd be great to have a better way to use the script. Currently you need to change your xcode config/ Android build config to use a different script

also it'd be great to auto-generate this file from .re-natal: https://github.com/pesterhazy/re-natal-husk/blob/master/husk-requires.js

I've brought it up with my guy and we think it's a good workaround. Currently, :advanced is both working around the timeout/OOM issues as well as giving us a smaller/faster bundle. For generating a non-prod APK, using :none or :simple, I think we'll go with your approach, but we don't yet have that need and are trying to meet some other deadlines.

yeah I know how it goes

:advanced is great as well

my approach should have advantages with advanced comp too - much faster bundling step

but i know it doesn't matter so much as long as it finishes

Yep, agreed that it would be faster. You should add a comment to that RN ticket, for any CLJS users who hit that issue again and need this.

I can also link the example repo I made there as well.

right, which ticket was that again?

https://github.com/facebook/react-native/issues/12590

Ok done

Nice. I'll follow up with my test repo in a bit.

Thanks for all your help with this.

it's an itch i wanted to scratch for a long time