Skip to content

Static import of my env vars and config breaks the usage of the libΒ #544

@gvko

Description

@gvko
  • I'm submitting a ...

    • Support request
  • What is the current behavior and expected behavior?

I have an index.ts file and a local.ts config file, which has some env vars. The config file looks like this:

export default {
  // different object props and their values
}

If I want to load the config at the start of my application, which runs the program, I can do it in two ways.

First one:

import * as dotenv from 'dotenv'
dotenv.config()
import localConfig from './local'

async function main() {
  let config: any = localConfig
  // start my app
}
main()

Second one:

import * as dotenv from 'dotenv'
dotenv.config()

async function main() {
  let config: any = (await import(`./local`)).default
  // start my app
}
main()

You can see that in the first way I use a static import and in the second, a dynamic import.
When I use a dynamic import, everything works, but when I use static import, I get the following error:

node_modules/.pnpm/@[email protected]_@[email protected]_@[email protected]/node_modules/@polkadot/wasm-crypto/cjs/bundle.js:46
      throw new Error('The WASM interface has not been initialized. Ensure that you wait for the initialization Promise with waitReady() from @polkadot/wasm-crypto (or cryptoWaitReady() from @polkadot/util-crypto) before attempting to use WASM-only interfaces.');

At the start of my app I call

await cryptoWaitReady()

And later on

    const keyring = new Keyring({ type: 'sr25519' })
    this.signer = keyring.addFromMnemonic(signer)

At .addFromMnemonic() is where the error is triggered.

I don't rly understand why this happens, because in both cases config is loaded correctly (with the signer that is used in the keyring), and await cryptoWaitReady() returns true, before I call the keyring initialization.

  • Please tell us about your environment:

    • Version: 6.4.1

    • Environment:

      • Node.js
    • Language:

      • TypeScript (tsc --version: 5.2.2)

Metadata

Metadata

Assignees

No one assigned

    Labels

    SupportTracks issues or requests related to troubleshooting, answering questions, and user assistance.

    Type

    No type

    Projects

    Status

    Support

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions