[expo] add getNativeModuleIfExists

[esamelson]

Why

follow up from #18892 -- we need a way for module authors to be able to do feature detection and bypass our errors

(also added missing ExpoRandom module to exclude list from the react-native-get-random-values lib)

How

Add getNativeModuleIfExists export from the expo package. If the native module doesn't exist, this method just returns null without throwing an error.

An alternative could be patching a method onto the NativeModules object itself, like NativeModules.getIfExists, which would mean external module authors wouldn't need to (perhaps conditionally) import this method from the expo package.

Test Plan

Tested by calling the following things in a test app (running in Expo Go):

• NativeModules.NonexistentModule -> throws error
• getNativeModuleIfExists('NonexistentModule') -> returns null
• getNativeModuleIfExists('LinkingManager') -> returns module

Checklist

• Documentation is up to date to reflect these changes (eg: https://docs.expo.dev and README.md).
• Conforms with the Documentation Writing Style Guide
• This diff will work correctly for expo prebuild & EAS Build (eg: updated a module plugin).

[ide]

Viewing this file (on mobile) it looks like we don't overwrite the NativeModules variable in this file. A benefit of not introducing originalNativeModules is that it becomes possible to call this new method even if createProxyForNativeModules hasn't yet been called.

Suggested change

	return originalNativeModules[moduleName];
	return NativeModules[moduleName];

[esamelson]

It doesn't quite work that well, unfortunately, because Object.defineProperty overwrites NativeModules everywhere, including this file if we import it. I've added it as a fallback in case originalNativeModules is null, though, which should cover the same case.

[ide]

could you try putting const originalNativeModules = NativeModules; in module-level scope (say, after the imports) and seeing if that works? I think what's happening is that NativeModules is always lazily accessed on the react-native module object, and introducing a new variable (originalNativeModules) will eagerly save the value of NativeModules.

[esamelson]

Ahh, that makes sense. Yes, this works -- thanks for the suggestion!

[brentvatne]

my only concern about this is that i don't think it will help developers who don't depend on the expo package to solve this problem -- react-native-get-random-values wouldn't be able to use this here: https://github.com/LinusU/react-native-get-random-values/blob/0a48c10a395c19affb9e24044a31e6e56afbf20a/index.js#L26-L38

that said, i don't know how we can do this without patching in a method like getIfExists

[esamelson]

Yeah, I think that's a reasonable point. Per @ide's comment here this would be best utilized in packages we maintain (though other module authors could do try { const { getNativeModuleIfExists } = require('expo'); ...). Not sure there is a very elegant solution for external libraries that use expo module fallbacks -- maybe the best thing for now is to just try maintaining a list of them and see how it goes.