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)
Indeed. Looking at the above code link promise is actually not properly tracked/handled -
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)