refactor(expotv): simplify Metro config by using Expo-provided monorepo config

[byCedric]

Hi! My name is Cedric, and I work on devtooling @expo. We saw this repository, and I thought I'd propose some simplifications on Expo's side. Feel free to ignore it, or use it 😄

Changes: simplify ExpoTV Metro config with default Expo monorepo support

1. Dropped manual config.watchFolders override
2. Dropped manual config.nodeModulesPath override
3. Dropped manual config.extraNodeModules override
4. Dropped manual config.blockList override
5. Dropped react-native-monorepo-tools as its unused after the changes

Note, both packages/vega and packages/shared are untouched.

Expo already comes with monorepo support out-of-the-box. It actually has a few additional things that you wouldn't be able to get with react-native-monorepo-tools, the biggest one being pnpm/bun with isolated dependencies support. Not only did we get this to work properly, we also switched our own monorepo to pnpm to improve maintenance overhead, DX in general with faster installs, and enforce workspace dependencies better. Since pnpm uses pnpm-workspace.yaml, I don't think you can get that to work with react-native-monorepo-tools.

We also have a few ideas we want to test for SDK 56 which could make config.watchFolders obsolete while also reducing the startup time from Metro through crawling. But, more on that later 😄

I also see that nodeModulesPath was configured, but I don't think this actually does anything. Metro documents it as following:

A list of paths to check for modules after looking through all node_modules directories. This is useful if third-party dependencies are installed in a different location outside of the direct path of source files. For more information, see Module Resolution.

Which means that it's mostly a fallback option, and with workspaces being set to pretty much always resolve, this fallback is never really hit. The same actually applies to extraNodeModules as well, if you look at Metro's own resolution documentation: https://metrobundler.dev/docs/resolution/

And lastly, blockList is kind of really slow. Unless you have a good reason to set it, which cannot be done through custom resolutions, I would avoid this at all costs.

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[byCedric]

I did test the changes through yarn install + cd packages/expotv; yarn ios. Seems to work great 😄

[anishamalde]

Hey Cedric! Thanks for taking the time to look at this and put together the PR! Really appreciate the Expo team reaching out directly - this makes sense and happy to simplify where we can 🥇

I had added the blockList as vega currently only supports React Native 0.72 (I know 😅) without blocking the Vega node_modules I was getting duplicate module resolution issues with the two different React Native versions.

Also keen to hear more about the SDK 56 changes around watchFolders when you're ready to share.

Thanks again!

[byCedric]

Haha, well, Expo gets lots of flack for not updating fast enough. We have to upgrade 🙈

I think blocking React Native 0.72 should not be necessary with #10. Which should guarantee this from the Metro's resolution and native autolinking layers. Maybe it makes sense to benchmark with and without Metro's blocklists, but I'm pretty sure it does make bundling slower the more resolution is done (the more files/modules it needs to bundle).

Any time 😄 I'm really excited about Amazon Vega and the push with React Native!