search

paritytech / frame-metadata

A set of tools to parse FRAME metadata retrieved from Substrate-based nodes.
Apache License 2.0
24 stars 10 forks source link

Generating and Publishing Equivalent TypeScript Types #32

Open harrysolovay opened 3 years ago

harrysolovay commented 3 years ago

I began to hand-write TypeScript type definitions corresponding to the shape of v14. This is of course error-prone. I'd imagine that other TypeScript developers are writing code that interacts with FRAME metadata. Would it be worthwhile to generate and publish corresponding TypeScript type definitions to NPM? Perhaps we could use ts-rs for the typegen?

If the answer to whether we should is a "YES"... does scale-info also then need to derive these typegen trait impls (for MetaForm)?

dvdplm commented 3 years ago

I don't understand what you're asking for here, likely because I don't know what you're trying to achieve (also: my TS chops are nonexistent). Can you ELI5 what such type defs would let you do that you can't do with the polkadot.js packages?

Can you give me an example of a hand-written type def that you'd like to auto-generate?

And on the flip side, were we to have this on npm, how would the maintenance of that look and why should developers be directed to use that rather than polkadot.js?

tl;dr: Can you elaborate? :)

harrysolovay commented 3 years ago

How do we enable more developers / tools to safely act on FRAME metadata? IMO, the first step is through reliable type definitions for other languages (starting with TypeScript), which should be generated from the source of truth (this repo's Rust source) as to be kept in sync.

In polkadot-js, these definitions have been generated here. These are––more or less––the types that I believe we should provide. However, they don't support the needs of developers who are not using the polkadot-js virtual type system. We can do better.

And to your point about maintenance: yes, it would mean integrating the NPM publish into the existing release process. I understand if this is a no-go. I only propose doing this codegen within frame-metadata because of the ease with which we could apply ts-rs for a desirable outcome. Seems there would be more overhead involved in creating a separate repo and configuring it to generate and publish with every frame-metadata release.

Curious to hear your thoughts!

ascjones commented 3 years ago

This was a usecase I had in mind when originally implementing "dogfooding" in scale-info, which would allow annotating the types here with TypeInfo, then using the metametadata from that to generate types...

Of course we now have https://github.com/paritytech/scale-info/pull/72, which has been languishing on my todo list to review.