-
Notifications
You must be signed in to change notification settings - Fork 14
Conversation
Rather than running the React Native packager in the appdir itself, create a Boot tmpdir, copy the required node_modules into it, and run the packager there. By running from a tmpdir, we can construct exactly the directory structure that the packager expects from a standard JavaScript project without needing to structure the boot fileset that way. This means we can play nicely with other boot tasks that the project might define -- such as other CLJS builds in the same project (ie non-React-Native code that shares a codebase with our React Native code).
Thanks, Travis!
I appreciate that this is a fairly sizeable change, so let me know if there's any questions I can answer. I implemented this because I'm introducing a React Native build to an existing project that already has a few React (web) ClojureScript builds, and I was having a lot of difficulty getting React Native to come up correctly in-place. It might have been possible for me to solve those problems solely by fixing up the handling of different output directories: I'm not sure. I spent some time going down that path, and failed, but that was probably before I understood some more of the under-the-hood details of how boot-react-native and boot itself all fit together. In any case, I prefer this solution -- where all intermediate boot-react-native output artefacts go to a temp directory only, never to the actual Worth mentioning that with these changes, and with adzerk-oss/boot-reload#70, I now have a setup where I can be running the iOS simulator and three separate React web builds, with substantial amounts of code shared between them, and have every single one of them correctly live-reload whenever I save a file. Thanks a ton for the library that's let me get to that point! |
I don't know why, but on a few occasions I've seen the bundle task fail, complaining that it can't find the transformer, if given a relative path instead of an absolute one. This doesn't appear to happen to the start-rn-packager task (well, at least, I haven't seen it happen there so far).
Thanks for this! My apologies, I've been pretty busy the past few weeks, so I haven't had time to check this out a lot. However, I really like this approach, and think it is the way forward. I've been thinking about adding functionality to automatically include React Native modules, but that'll need something like this to work. I'll merge this, but as I said, I'm currently pretty busy so my response is going to be slower for the next few weeks. Let me know if want commit access for future changes. |
Can you try running the example app on your machine - I'm getting "Cannot find entry file index.android.js in any of the roots" after applying the pull request, running |
I'm a bit embarrassed to admit that I didn't really play much with the example project. No, it doesn't run for me either as-is. I can get it to run, though, by changing the example's
(ie adding the I vaguely remember something that stumped me for a while re I've gotta run off right at the moment, but I'll look into this a little more to figure out what's changed. Obviously for the |
Thanks, no big rush. Looking at it, it seems that we just need to copy over index.android.js and index.ios.js to the work dir in |
Oh, right. I don't use an |
Re being able to see what I did: if you're interested, here's a gist of my |
Rather than running the React Native packager in the appdir itself,
create a Boot tmpdir, copy the required node_modules into it, and run
the packager there.
By running from a tmpdir, we can construct exactly the directory
structure that the packager expects from a standard JavaScript
project without needing to structure the boot fileset that way. This
means we can play nicely with other boot tasks that the project might
define -- such as other CLJS builds in the same project (ie
non-React-Native code that shares a codebase with our React Native
code).