fix: fix error in bridgeless due to nativeCallSyncHook

[itsramiel]

Hi,

Closes #779

Apps running on bridgless, old arch always has nativeCallSyncHook as undefined making this:

react-native-mmkv/src/createMMKV.ts

Lines 49 to 53 in 6682adf

	if (global.nativeCallSyncHook == null || MMKVModule.install == null) {
	throw new Error(
	'Failed to create a new MMKV instance: React Native is not running on-device. MMKV can only be used when synchronous method invocations (JSI) are possible. If you are using a remote debugger (e.g. Chrome), switch to an on-device debugger (e.g. Flipper) instead.'
	);
	}

always throw.

Check this guide on insuring the interop layer:

[JavaScript] global.nativeCallSyncHook can't be used to detect legacy "Remote Debugging in Chrome" with JSC

global.nativeCallSyncHook === 'undefined' is a common way to check if you're running in "Remote Debugging in Chrome" (which is not supported with Hermes, only JSC). This is often used to provide some fallback behavior for sync native functions, because they do not work in the legacy remote debugging environment. Use "RN$Bridgeless" in global && RN$Bridgeless === true to determine if you are running in bridgeless. Learn more in LinusU/react-native-get-random-values#57.

It is generally not recommended to fork behavior based on whether bridgeless is enabled — this is an escape hatch that should be used sparingly.

Example "isRemoteDebuggingInChrome()" function

function isRemoteDebuggingInChrome () {
  // Remote debugging in Chrome is not supported in bridgeless
  if ('RN$Bridgeless' in global && RN$Bridgeless === true) {
    return false
  }

  return __DEV__ && typeof global.nativeCallSyncHook === 'undefined'
}

⚠️ Not sure which branch to base on. Is there a 2.x.x maintenance branch?

[mrousavy]

Hey - thank you for your PR, I appreciate it, and I especially appreciate the detail that went into explaining the issue.

⚠️ Not sure which branch to base on. Is there a 2.x.x maintenance branch?

Unfortunately no - I already don't have enough time to maintain all my react native repositories, so if I would also maintain backwards compatibility then I would have no time at all anymore.

So there's unfortunately nothing I can do with this PR - the new main branch of react-native-mmkv doesn't have this issue because it uses an all new C++ TurboModule implementation.

Hope you understand.

[itsramiel]

Got it. Thank you!