ignite
ignite copied to clipboard
infinitered
Docs: Monorepo setup guide
I'd like to add a monorepo setup guide to Ignite's docs. It's a common request these days, and is not a straightforward process (took us a week recently on one client's project).
It would live in ./docs/Monorepo-Setup-Guide.md most likely.
cc @kevinvangelder @leonskim
In the last few months, I think I have explored all the possible solutions to create a monorepo with react native. To ship a /mobile app and a /web app to production.
My 2 cents on this:
Solito
expo + nextjs
Example: https://github.com/flexbox/react-native-nextjs-monorepo used https://solito.dev
It's a powerful solution for small/medium teams working on a new project.
Problems I faced:
- opinionated solution —which is good! but in my case, I needed to add Native Base and I ended up having issues with webpack to make things work.
Should I recommend it?
Yes! The doc is up-to-date, @nandorojo has put a lot of effort into this solution.
Took me 3 hours to setup a project, add a UI library react-native-paper and ship it to production on Vercel.
Does it benefit Ignite? Not sure.
Universal Monorepo
Android - iOS - Windows - MacOS - Android TV - tvOS - Web - Web - Browser Extension - Web - Electron - Web - Next.js
Example: https://github.com/flexbox/react-native-universal-monorepo used https://github.com/mmazzarolo/react-native-universal-monorepo
Problems I faced:
- Same as before, trying to add a Native Base and make it work on ALL platforms.
Should I recommend it? Not really, it's a nice learning resource tho! but I encountered a lot of headaches trying to bump all the dependencies
Does it benefit Ignite? I don't think so. It's a nice reference to have if you want to work with yarn workspaces.
Nx
react-native + react-native-web
Example: https://github.com/flexbox/react-native-nx-monorepo used https://nx.dev/packages/react-native
From my perspective, it's more for a big team where there is a dedicated person —like a software architect— to setup and educates other devs to work with this stack.
Problems I faced:
- The learning curve, reading this book helped me to ramp up on "thinking in monorepo" https://go.nrwl.io/react-book
Should I recommend it? Yes! The DX is mindblowing. There is documentation and that's what "Big Enterprises Corporations" are looking for: how to maintain software over time.
Does it benefit Ignite? Could be. Nx allows you to share code / write test (kind of the same as ignite generators but at a monorepo level) —right now I have 3 different react apps living in harmony in the same repo Nx is a maintained product with a dedicated engineering team. You should catch up with @xiongemi she writes articles on medium.
Was there any reason why Ignite migrated away from monorepo? Would be great if we could weigh the pros and cons in the doc as well.
what happened to this issue? And I'm wondering why there is no @nx/ignite at par with @nx/expo and @nx/react-native?
@flexbox - kudos to awesomely compiled response above; I'm curious, did you also try ignite-cli generated app in a monorepo setup such as nx? Thanks.
And I'm wondering why there is no @nx/ignite
because infinite red is not a GAFAM, FAAM, whatever giant tech company with thousands of engineer available to maintain it 😅 And they are busy with other awesome things. In a ideal world we could have such, but the reality is every company tend to have their own monorepo solution based on their needs. So there is no point trying to please everyone were the "problem" is more politic / organisational and not really a tech issue.
did you also try ignite-cli generated app in a monorepo setup such as nx
No because i work as a freelance. I do not feel confident to scaffold an "exotic solution" and leave the team alone without any documentation. I think you can, but i would not recommend because you will spend time on plumbing (especially if you want to share stuff following the nx way) instead of shipping actual features to your users/products.
@astriskit what kind of app are you building that needs a monorepo?
@flexbox thanks for answering. And agreeable reasoning. :)
App is for a fintech product in crypto space. The plumbing that I was engaged up till like yesternight here has come to a bitterness of overdoing it; I wanted to fill it (sort of re-starting and exploring) with kitchen-sink for web and mobile along with a shared space for a web app. But in light of the real work(the features, screens, current-scope, team, etc.), this became tiny and insignificant very fast for the project - nothing writing some e2e and unit tests can't cover, I believe; Web-app can also be built through the expo/metro rather than shelling it in a separate app (using a different stack). That being said, it was a learning streak - nx, yarn workspaces, @nx/expo, @nx/react, monorepo setups.
Partly our reasoning for not offering a monorepo setup is companies often come to Infinite Red to plug a React Native app into their existing monorepos, which means we need to be pretty adaptable and flexible.
With that said, this is on my radar to improve.
Reactotron has a monorepo with an example ignite app embedded in it:
https://github.com/infinitered/reactotron/blob/master/apps/example-app
Reactotron uses nx as a task runner but not much else of nx features. This would be a good example to reference of what it would look like to setup an app in a yarn 3 monorepo setup.
Here is the initial PR @morganick created that could be useful for reference
https://github.com/infinitered/reactotron/pull/1411
In general, the most complicated part of a monorepo setup is making sure that all the config files in the root of an ignite app workspace resolve correctly:
- metro.config.js: Metro can resolve, watch, and link any workspace aliases
- babel.config.js: Metro/Babel can resolve any workspace aliases for the JS bundle
- tsconfig.json: Typescript can resolve workspace aliases for type checking
- react-native.config.js: if you are using React Native CLI instead of Expo for some reason, it needs to know where to resolve workspace aliases
The other tricky part is what package manager you use. npm, yarn, pnpm, and bun all have subtle nuances that affect where workspaces and node_modules are resolved from. These differences are part of why it's tricky to make one true recipe.