Library compatibility with Secure EcmaScript

Secure EcmaScript proposal: https://github.com/tc39/proposal-ses

Steps to reproduce:

Only way we know how to reproduce is to run build on: https://github.com/NodeFactoryIo/metamask-snap-polkadot/tree/feature/connect-to-node

Error:

Build success: 'build/index.js' bundled as 'dist/bundle.js'!
Snap evaluation error: possible import expression rejected around line 8527

Code: Which makes no sense as that line contains comment so it might be due to snap evaluation code.

[jacogr]

1.8.0-beta.10 allows the initWasm: false flag which would skip init on the API level itself. Please give it a try as see if it gets down the road somewhat. (As mentioned, not having wasm means no sr25519 support, which depending on use is ok or not)

The util-crypto will still try imports from wasm-crypto in the utils to determine which path to take, i.e. if wasm is available it will use that, otherwise fallback. If this creates an issue, there would need to be some magic in the util-crypto done.

So if the flag itself does not get over the line, the stub of wasm-crypto is the other approach. In the project package.json -

"browser": {
    "@polkadot/wasm-crypto": "./noWasm"
  },

Where the noWasm.js file has the following -

export function isReady () {
  // always false, when true it will try and use non-existent functions
  return false;
}

export function waitReady () {
  // always immediate true, our process is done
  return Promise.resolve(true);
}

• the waitReady is what is called on init
• the isReady is what is called when the libs determine which path to take

(This is the hammer approach, even without the flag introduced it will just stub out the wasm completely, all ok for any hashing or ed25519 keys that can take either route)

[polkadot-js-bot]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.