LinusU / react-native-get-random-values

A small implementation of `getRandomValues` for React Native
MIT License
350 stars 48 forks source link

`null is not an object` error for getRandomBase64 when running with Expo SDK 40.0.0 #25

Closed grantaveryatgfs closed 3 years ago

grantaveryatgfs commented 3 years ago

Hello, I'm working on upgrading my project to Expo 40 from 39, but I'm running into this error in the getRandomBase64.js file of react-native-get-random-values on both iOS and Android. After some playing around with the package code, it appears that RNGetRandomValues is null.

image

One point of confusion is why my code would even hit getRandomBase64.js, since it is on the managed workflow and https://github.com/LinusU/react-native-get-random-values/pull/13 seems to say that my project should be hitting the getRandomBase64.expo.js version instead. If I force that (by running the getRandomBase64.expo.js code in getRandomBase64.js), I don't get the error any more (I get a different error about AsyncStorage, but that appears to be further down the line and not related to this package). When I run the same project and same package with SDK 39, I don't get the error and I can confirm that it is successfully running the .expo.js version of getRandomBase64 (NativeModules.ExpoRandom.getRandomBase64String). If I force the project with SDK 39 to hit NativeModules.RNGetRandomValues.getRandomBase64, it errors as expected.

Has something changed between SDK 39 and 40 that would cause this issue between the .expo.jsand .js files, either on the package side or the SDK?

(EDIT: fixed a mismatched reference to the two different getRandomBase64 files)

LinusU commented 3 years ago

Has something changed between SDK 39 and 40 that would cause this issue between the .expo.jsand .js files, either on the package side or the SDK?

@brentvatne are you familiar with any changes to Expo in SDK 40 which could have caused this? šŸ¤”

brentvatne commented 3 years ago

my guess is that you are using a custom metro.config.js that does not extend @expo/metro-config: https://docs.expo.io/guides/customizing-metro/

from release notes:

Screen Shot 2021-01-27 at 9 59 47 AM

if this isn't the case, let me know and create a mcve and i can look into it more

grantaveryatgfs commented 3 years ago

Hi Brent, thanks yeah it looks like I missed that step. Making the required metro-config changes resolves my current error, but now I'm running into two separate errors, one for each iOS and Android (we don't deploy to web or Windows), do you have any idea why I'd be hitting them?

On Android the app opens but displays this warning in console and in the app. I've read the expo.fyi and confirmed that my codebase contains no "__expo." or "Expo." references (including node_modules), so it's strange that I'd be running into this warning in the first place.

Your project is accessing the following APIs from a deprecated global rather than a module import: Constants (expo-constants).

The global "__expo" and "Expo" objects will be removed in SDK 41. Learn more about how to fix this warning: https://expo.fyi/deprecated-globals

- node_modules/react-native/Libraries/LogBox/LogBox.js:117:10 in registerWarning
- node_modules/react-native/Libraries/LogBox/LogBox.js:63:8 in warnImpl
- node_modules/react-native/Libraries/LogBox/LogBox.js:36:4 in console.warn
- node_modules/expo/build/environment/react-native-logs.fx.js:18:4 in warn
- node_modules/expo/build/deprecatedGlobal.js:18:4 in logWarning
- node_modules/react-native/Libraries/Core/Timers/JSTimers.js:130:14 in _callTimer
- node_modules/react-native/Libraries/Core/Timers/JSTimers.js:383:16 in callTimers
- node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js:416:4 in __callFunction
- node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js:109:6 in __guard$argument_0
- node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js:364:10 in __guard
- node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js:108:4 in callFunctionReturnFlushedQueue
* [native code]:null in callFunctionReturnFlushedQueue`

On iOS the app doesn't open, just crashes with SIGABRT and errors in console. Nothing appears in the simulator System Log, so that doesn't help me. We're resolving the module.exports (in metro.config.js) with an async call so I tried wrapping the contents in a try/catch, but that didn't help.

(node:44624) UnhandledPromiseRejectionWarning: Error: xcrun exited with signal: SIGABRT
    at ChildProcess.completionListener (/Users/{REDACTED}/.nvm/versions/node/v14.15.4/lib/node_modules/expo-cli/node_modules/@expo/spawn-async/src/spawnAsync.ts:64:13)
    at Object.onceWrapper (events.js:422:26)
    at ChildProcess.emit (events.js:315:20)
    at maybeClose (internal/child_process.js:1048:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:288:5)
    ...
    at spawnAsync (/Users/{REDACTED}/.nvm/versions/node/v14.15.4/lib/node_modules/expo-cli/node_modules/@expo/spawn-async/src/spawnAsync.ts:26:19)
    at xcrunAsync (/@expo/xdl@59.0.19/src/SimControl.ts:405:18)
    at Object.bootAsync (/@expo/xdl@59.0.19/src/SimControl.ts:162:11)
    at action (/@expo/xdl@59.0.19/src/Simulator.ts:310:25)
    at waitForActionAsync (/@expo/xdl@59.0.19/src/Simulator.ts:292:22)
    at ensureSimulatorOpenAsync (/@expo/xdl@59.0.19/src/Simulator.ts:207:24)
    at Object.openProjectAsync (/@expo/xdl@59.0.19/src/Simulator.ts:674:14)
    at ReadStream.handleKeypress (/Users/{REDACTED}/.nvm/versions/node/v14.15.4/lib/node_modules/expo-cli/src/commands/start/TerminalUI.ts:228:11)
(Use `node --trace-warnings ...` to show where the warning was created)
(node:44624) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:44624) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
brentvatne commented 3 years ago

@grantaveryatgfs - your code definitely accesses a global expo property somewhere, that is the only way that you would get that warning (implementation: https://github.com/expo/expo/blob/f266600485270472412f2072235bcd8ec45d3c7e/packages/expo/src/globals.ts / https://github.com/expo/expo/blob/f266600485270472412f2072235bcd8ec45d3c7e/packages/expo/src/Expo.fx.expo.tsx#L52-L63).

as for the other error that you're encountering, it seems like maybe there's a problem with your simulator? sadly it can be a problematic sometimes. https://forums.expo.io/t/running-project-on-ios-simulator/43413/3

if all else fails, i'd suggest doing some manual debugging: https://github.com/expo/fyi/blob/master/manual-debugging.md


@LinusU - feel free to close this issue and @grantaveryatgfs can repost to https://forums.expo.io or https://github.com/expo/expo/issues if he has some other issues

grantaveryatgfs commented 3 years ago

Hmm, I don't know where else I could check to find why one of those globals could be. I've made sure I'm searching all files ( no .gitignore) in the repo directory. All the instances of "constants" use an expo-constants import. image

You're corrrect on the second point, I was able to reset my simulator and the run error went away (revealing the expo globals warning).

brentvatne commented 3 years ago

you probably have node_modules in your gitignore and it's being skipped in your search.

also, it can be exposed under any of these properties:

    global.__exponent = globals;
    // @ts-ignore
    global.__expo = globals;
    // @ts-ignore
    global.Expo = globals;

so __exponent., __expo., or Expo.

grantaveryatgfs commented 3 years ago

Like I said, I removed everything from my gitignore so that isn't a factor. I've searched for each of those specific examples but there's nothing.

I'll keep thinking of possibilities, but I'm at a loss for where these references could be hiding.

grantaveryatgfs commented 3 years ago

Whelp, apparently VSCode and Finder weren't indexing/showing literally all files/file contents, because if I search in Intellij by Directory for all places I see the culprit is in our version of react-native-paper (https://github.com/callstack/react-native-paper/blob/3.0/src/components/MaterialCommunityIcon.tsx#L20-L25). I should be able to update that to a newer version and resolve the issue. Thanks, and sorry for taking up your time šŸ˜