Fork me on GitHub

I’ve tried out a potential Android fix for OSX out of memory during bundle, but to no avail: It still fails with an Uncaught error in the transformer worker unless --dev true. Anybody got bundle to complete on Android with --dev false? Here is what I used: node --max_old_space_size=4096 node_modules/react-native/local-cli/cli.js bundle …


I also tried modifying nodemodules/react-native/packager/packager.sh_ injecting --max_old_space_size=4096 in the node invocation, but that didn’t do the trick either.


I've fixed this problem much more straight-forward way. I just created separate packager dir in the root of my project, placed updated versions of react.gradle and and made my iOS and Android projects use these two files instead of the two ones provided by React Native team. I think this solytion is better because in the case of update/upgrade or removal of node_modules directory you won't lose anything.


@alwx: The solution that seantempesta offered is trackable in git hence not lost in node_modules, albeit it could be overwritten if not careful, by the step by step react-native upgrade but I still have to do that carefully in order not to break other things so for me that solution works.


Interesting to hear that everyone that has worked for a while on a clojurescript app in RN encounter this issue. The size of the compiled js must be significantly bigger. Not that it matters much for RN.


I wonder if the RN packager would yield more performant code if one would tweak the closurescript compiler to return ES6 instead of default ES3? Have very little knowledge in these things but I found it interesting.


well you can try (from

Configure the input and output languages for the closure library. May be :ecmascript3, ecmascript5, ecmascript5-strict, :ecmascript6-typed, :ecmascript6-strict, :ecmascript6 or :no-transpile.

Defaults to :ecmascript3

:language-in  :ecmascript3
:language-out :ecmascript3


@artemyarulin: Yes exactly, seeing those options for the compiler was what got me thinking. Not worth investigating if there are not reason that there would be performance gains though.


yeah, didn’t see those before - previously only es3 and es5 was available. It was added on Feb 16, but yeah - also interesting to see the output of ES-typed 🙂


sightly offtopic - any body played with clojure.spec already? Looks amazing


@artemyarulin: Replacing schema with spec as we speak 🙂


So CLJS has a full support for it already? I read somewhere that test.check is not available yet


There are some things missing merge function and super slick namespaced map reader are the ones I have encountered. Haven’t gotten to the testing part yet.


good, but basics works which is most important thing. Cool, thx


cannot wait when all the libraries (including standard one) would be cover with spec


I know, that will be awesome.


Since you can pprint the errors from explain-data the error messages can actually be quite informative. Strange experience since I'm developing clojure most of my time 😉


but what the usual way - I thought you just cover all your important functions with fdef and then somewhere at the beginning of a REPL session you call (instrument) and after that all function calls got checked, and in case of fail - it throws?


I haven’t gotten that far, still working on replacing the verification of app-db. Sounds excellent though.


yeah, I also know almost nothing about that. Thanks in any case, I guess we would see more examples once 1.9 got released


I’m using spec for form validation and data coercion. It seems like a natural fit so far.