cosmjs
cosmjs copied to clipboard
import("crypto") issues with React Native
This was originally brought up by @mvid in https://github.com/cosmos/cosmjs/pull/1307. import("crypto") seems to be an issue for the React native bundler.
This is strange since the point of import("crypto") is that it can fail at runtime, right? So it should be the tool of choice I guess.
https://github.com/paulmillr/noble-secp256k1 takes a different approch. They say import * as nodeCrypto from 'crypto'; and then in package.json have:
"browser": {
"crypto": false
},
But is this standardized? Or just for the rollup build? On npm the description for browser is a different one: https://docs.npmjs.com/cli/v9/configuring-npm/package-json#browser. Here are some notes but is this established?
In https://github.com/cosmos/cosmjs/pull/1340 I changed the getSubtle() implementation but all the comments there are wrong since Node.js and the Node.js REPL behave differently.
I don't know if the change in https://github.com/cosmos/cosmjs/issues/1341 makes sense since we have no subtle support in Node.js. So every non-browser environment would use the JS-only implementation.
@webmaster128 specifically the import over require seems to be specific to Metro bundler. I am not sure why it behaves this way, and haven't been able to get straight answers out of the docs. I "solved" the problem by forking cosmjs and removing the import entirely, and depending on crypto being shimmed into globalThis
My vote would be to ignore node crypto entirely, and have the user provide their own crypto library in config/shim
My vote would be to ignore node crypto entirely, and have the user provide their own crypto library in config/shim
The main issue I see here is that it is not only our choice. Many dependencies pull in a crypto dependency one way or another. Also there are different crypto APIs. The one defined as Crypto here is a different one than require("crypto").
Weird, I have no problems with latest react native importing 'crypto'

Yeah, it works with the static import. But the dynamic import statement causes trouble. This is very unfortunate since we explicitly want to use dynamic imports in order to allow them to fail at runtime :/