api: Typegen Usage which worked with 9.14.2 doesn't work with 10.1.2

  • I’m submitting a …

    • Bug report
    • Feature request
    • Support request
    • Other
  • What is the current behavior and expected behavior?

Code which worked with @polkadot/api v9.14.2 doesn’t work with v10.1.2. – Likely same as https://github.com/polkadot-js/api/issues/5524#issuecomment-1468321718

Some clarification on what changes are needed would be useful.

Example code (& the commands used) can be found here: https://github.com/rgoulter/polkadot-js-typegen-efinity – It’s a pretty bare-bones usage of typegen, to generate the code, and includes a small example TypeScript program which uses the generated types.

The latest commit there updates the @polkadot/typegen to 10.1.2 (and in example/package.json, its @polkadot/api to 10.1.2).

I’m having trouble figuring out what changes I need to make to get it to work with 10.1.2.

What goes wrong:

When it runs polkadot-types-from-defs, it has problems loading the definitions.ts:

> ts-node --skip-project node_modules/.bin/polkadot-types-from-defs --package @efinity/api-augment/interfaces --input ./src/interfaces --endpoint ./metadata.json

ERROR: Unable to load user definitions: Unknown file extension ".ts" for /home/rgoulter/scratch/efinity-api-augment/src/interfaces/definitions.ts

When running polkadot-types-from-chain, some .ts code is generated, but the generated code then leads to errors when trying to build it.

> ts-node --skip-project node_modules/.bin/polkadot-types-from-chain --endpoint ./metadata.json --output ./src/interfaces

Generating from metadata, 254,086 bytes
ERROR: No lookup definitions found: Unknown file extension ".ts" for /home/rgoulter/scratch/efinity-api-augment/src/interfaces/lookup.ts
2023-03-15 14:41:52        REGISTRY: Unknown signed extensions CheckFuelTank found, treating them as no-effect
/home/rgoulter/scratch/efinity-api-augment/src/interfaces/augment-api-consts.ts
        Generating
        Writing

...

Sample errors when trying to run tsc in example:

node_modules/@efinity/api-augment/src/interfaces/augment-api-consts.ts:166:17 - error TS2304: Cannot find name 'FrameSupportPalletId'.

166       palletId: FrameSupportPalletId & AugmentedConst<ApiType>;
                    ~~~~~~~~~~~~~~~~~~~~

...

Found 457 errors in 4 files.

Errors  Files
    11  node_modules/@efinity/api-augment/src/interfaces/augment-api-consts.ts:166
   142  node_modules/@efinity/api-augment/src/interfaces/augment-api-events.ts:43
    86  node_modules/@efinity/api-augment/src/interfaces/augment-api-query.ts:31
   218  node_modules/@efinity/api-augment/src/interfaces/augment-api-tx.ts:23

Problems running with ts-node-esm, too:

If instead of ts-node, I try ts-node-esm, polkadot-types-from-defs abruptly exits without an error message:

> ts-node-esm --skip-project node_modules/.bin/polkadot-types-from-defs --package @efinity/api-augment/interfaces --input ./src/interfaces --endpoint ./metadata.json

/home/rgoulter/scratch/efinity-api-augment/src/interfaces/types.ts
        Generating
        Extracting interfaces for default

If instead of ts-node, I try ts-node-esm, polkadot-types-from-chain is still unable to lookup the definitions:

> @efinity/api-augment@0.0.1 generate:meta
> ts-node-esm --skip-project node_modules/.bin/polkadot-types-from-chain --endpoint ./metadata.json --output ./src/interfaces

Generating from metadata, 254,086 bytes
ERROR: No lookup definitions found: Cannot read properties of undefined (reading 'default')
2023-03-15 14:45:04        REGISTRY: Unknown signed extensions CheckFuelTank found, treating them as no-effect
/
...
  • What is the motivation for changing the behavior?

n/a

  • Please tell us about your environment:

Linux.

$ node --version
v18.12.1

$ npx tsc --version
Version 4.9.4

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 21 (12 by maintainers)

Most upvoted comments

Indeed. Looking at the above code link promise is actually not properly tracked/handled -

  • it does resolve when a response is received (all good)
  • it does not reject onerror, rather exits (same with close)

So basically that should be adjusted to only resolve/reject once (onmessage/onerror/onclose) aka when we have a response, we don’t care if things go wrong with the connection so should not perform any exit inside there. Said differently whichever of there we find once should determine the Promise result… once.

(It seems it was expecting all RPCs nodes to always behave and that assumption doesn’t always hold)

10.1.3 patch release is out that fixes the (completely incorrect), .module. specifiers. That has been tested against the above repo (with module & loader flags as per the PR just above that introduced the changes)