Update default-crypto-instances.ts

[Sydwell]

The latest React projects complains the existing code has a top level await. This proposed change returns the same variables but not as promises.
The code may look a little "hacky" but the traditional way of solving is issue using IIFE doesn't work.
ie: this doesn't work:
(async() => {
const [sha1, sha256, sha512, ripemd160, secp256k1] = await Promise.all([
instantiateSha1(),
instantiateSha256(),
instantiateSha512(),
instantiateRipemd160(),
instantiateSecp256k1(),
]);
})();
export { ripemd160, secp256k1, sha1, sha256, sha512 };

[changeset-bot]

⚠️ No Changeset found

Latest commit: 17ab932

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[Sydwell]

Please review, Should not have any breaking issues.

[jimtendo]

I think this might cause race-conditions in some cases. For example, if I have a NodeJS script that immediately attempts to execute a hashing operation at its entry point like so:

node index.js

import { hexToBin, sha256 } from '@bitauth/libauth';

// 32 byte hex payload
const hexPayload = '00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff';

// I'm not sure if we have a guarantee that sha256 will be instantiated at this point because the crypto WASM promises may not have resolved
sha256.hash(hexToBin(hexPayload));

You might be able to get around this by setting your tsconfig.json (and whatever build/bundler you're using) to target something after ES2022 (where top-level-awaits were standardized IIRC):

tsconfig.json

{
  // ...
  "compilerOptions": {
    "target": "esnext",
    "module": "esnext",
    // ...
  }
}

I think this would also break the typing where the WASM functions are injected automatically as arguments to other functions too (because sha256, etc, are now typed as a Promise as opposed to a Resolved Promise).

There's a bit of cross-over that might help here (that shows, roughly, how to configure Vite):

#137 (comment)