docs: Information about version compatibility and a note about expo in metro config docs

[MatiPl01]

Summary

This PR adds version compatibility information to metro config docs. This change is motivated by the fact that I received a few messages from people who got stuck on this configuration step and wondered why it doesn't work.

I also noticed that this wrapper doesn't change anything if someone uses expo/metro-config instead of the default React Native @react-native/metro-config config (e.g. someone creates an Expo-managed project instead of a bare workflow). I added information about this to notes.

Example images

Getting Started

Accurate Call Stacks

Added the Important note box and the Version Compatibility section

Added these 2 remarks:

[MatiPl01]

This also was confusing for some people who copied code from this example with the empty config and wondered why RN app doesn't start. I don't know how to best represent this in code, so I just removed config so that people can think for a while what this config should be before starting the app.

I think that the best way to represent this would be to show something similar to git diff but I don't know if we have this functionality already added in docs.

[hirbod]

We're not using expo/metro-config, but getSentryExpoConfig, which is based on it.
Furthermore, we wrap withNativeWind.

Any insights what to do here? Should we wrap? Is the order important?

Right now, we export like so:

module.exports = wrapWithReanimatedMetroConfig(
  withNativeWind(config, {
    input: './global.css',
    inlineRem: 14,
  })
)

While config is

const config = getSentryExpoConfig(projectRoot)

I don't see any issues, but want to double check.

[MatiPl01]

We're not using expo/metro-config, but getSentryExpoConfig, which is based on it.

I checked how getSentryExpoConfig is implemented and, basically, it extends the @expo/metro-config (see this function).

What @expo/metro-config does is very similar to what we do in reanimated. In general, it implements a custom symbolicator (see this line). The implementation of this function can be found in this file. When you scroll up, you can see the regex patterns array which excludes all stack frames from node_modules (here is this pattern). Thanks to this, user gets better errors/warnings, which point to their code instead of the library source code.

On the contrary, the default React Native metro config excludes only some paths from node_modules, so all errors thrown from third party libraries will show the internal library source code in stack traces. We wanted to tackle this problem by implementing our custom metro config wrapper, which does only one thing (similar to expo's config), it adds the custom symbolicator that filters out all frames from the stack trace that point to node_modules/react-native-reanimated. We don't filter out all frames from any package in node_modules like expo does, we only filter out these pointing to reanimated (you can see our simple implementation here)

Summing up, if you already use getSentryExpoConfig, which extends expo/metro-config, adding wrapWithReanimatedMetroConfig will make no changes as expo's config already filters out all stack frames from node_modules, so reanimated error/warning stack frames are also included.

tl;dr

You can safely remove wrapWithReanimatedMetroConfig from your metro config and everything will still work the same as it works now.

[MatiPl01]

@hirbod

If you want to make sure that you get readable errors with clean stack traces, you can purposely use reanimated's API in the wrong way. e.g. you can call the getViewProp method with invalid view tag, such as:

getViewProp(-1, "prop");

If you see error similar to this, that shows getViewProp call instead of reanimated internals, your metro config doesn't need the reanimated wrapper.

[hirbod]

Thank you so much for the clarification. I'll test and report back

[tjzel]

Please DRY these changes as we discussed offline.