[docs] Keeping the bundle size small in bare apps with exclude #9736
Comments
|
hi there!
the following pages are added via react-native-unimodules: expo/packages/react-native-unimodules/package.json Lines 42 to 57 in 714a594 first, you don't need to exclude any of the interfaces. they empty js files and one or two header files that allow distinct modules to depend on functionality from other modules by requesting a module that implements an interface. these will have no size or performance impact on your app when it's built. second, you almost certainly want expo-asset, expo-file-system (required by expo-asset), expo-constants, and expo-permissions. these are used by every app, through apis like so what's left? if you have the expo/packages/expo/package.json Lines 59 to 70 in 714a594 you may want to remove expo-sqlite, expo-splash-screen (although i'd recommend keeping it), expo-location, and expo-linear-gradient. up to you.
the only impact this will have is on your |
Done to reduce boring mocks (in particular, remove boring mocks for things from Expo) in our Jest setup. A redo of 62621ef and e40c020, reverted in 347aa96, which we can do following the recent RN upgrade to v0.62 (see 347aa96 for details). Since we're on [email protected], use 16.11.0 as the version range for react-dom, instead of 16.9.0 as we did in 62621ef. (We don't use any code in react-dom, but we unfortunately have to include it to satisfy peer dependencies; see 62621ef.) This time around, we get a peer-dependency warning suggesting we need to install expo-splash-screen: """ warning "jest-expo > @expo/config > @expo/[email protected]" has unmet peer dependency "expo-splash-screen@*". """ So, do that. It really should go under `devDependencies`, since we only need it for jest-expo. But I find that react-native-unimodules is automatically linking `expo-splash-screen`'s native code on iOS and Android, whether it's in `devDependencies` or `dependencies`. Although I didn't encounter problems building and running for release on iOS or Android with this in `devDependencies`, it seems problematic to link native code from a package we've said is for development only. So, reluctantly, say that it's not for development only. We may in fact want to use it in production one day; if we do, we'll probably need to put together a Flow libdef. [1] We can't prevent this from happening in the usual way, by adding lines to `react-native.config.js`; it seems Unimodules isn't informed by that file, which is where React Native's autolinking (a separate process) takes its cues from. There may be a way to tell Unimodules to exclude it, but it seems to mean calling code in two or three places that's mostly meant for internal use; see https://forums.expo.io/t/unimodules-what-else-can-i-exclude/41079 and expo/expo#9736 (comment).
Done to reduce boring mocks (in particular, remove boring mocks for things from Expo) in our Jest setup. A redo of 62621ef and e40c020, reverted in 347aa96, which we can do following the recent RN upgrade to v0.62 (see 347aa96 for details). Since we're on [email protected], use 16.11.0 as the version range for react-dom, instead of 16.9.0 as we did in 62621ef. (We don't use any code in react-dom, but we unfortunately have to include it to satisfy peer dependencies; see 62621ef.) This time around, we get a peer-dependency warning suggesting we need to install expo-splash-screen: """ warning "jest-expo > @expo/config > @expo/[email protected]" has unmet peer dependency "expo-splash-screen@*". """ So, do that. It really should go under `devDependencies`, since we only need it for jest-expo. But I find that react-native-unimodules is automatically linking `expo-splash-screen`'s native code on iOS and Android, whether it's in `devDependencies` or `dependencies`. Although I didn't encounter problems building and running for release on iOS or Android with it in `devDependencies`, it seems problematic to link native code from a package we've said is for development only. So, reluctantly, say that it's not for development only, by putting it under `dependencies`. We may in fact want to use it in production one day; if we do, we'll probably need to put together a Flow libdef. [1] We can't do the usual thing to prevent it from getting linked, adding lines to `react-native.config.js`. It seems Unimodules isn't informed by that file, which is where React Native's autolinking (a separate process) takes its cues from. There may be a way to tell Unimodules to exclude it, but it seems to mean calling code in two or three places that's mostly meant for internal use; see https://forums.expo.io/t/unimodules-what-else-can-i-exclude/41079 and expo/expo#9736 (comment).
Improvement for https://docs.expo.io/bare/installing-unimodules/ (or maybe a new page in /bare relating to app performance?)
see https://forums.expo.io/t/unimodules-what-else-can-i-exclude/41079/3
I would like to avoid integrating with unnecessary modules and bloating my app. Since there is only a denyList exclude option and not an allowList include option- how can I get the full list of excludable modules?
Also, modules excluded in native integrations are still unnecessarily downloaded into /node_modules. I would love the documentation to show steps for removing excluded node_modules safely.
Request:
How can I get the full list of excludable modules?
How can I remove excluded modules from node_modules?
Any other tips for keeping the bundle small in the bare workflow.
The text was updated successfully, but these errors were encountered: