Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generating and Publishing Equivalent TypeScript Types #32

Open
harrysolovay opened this issue Nov 14, 2021 · 3 comments
Open

Generating and Publishing Equivalent TypeScript Types #32

harrysolovay opened this issue Nov 14, 2021 · 3 comments

Comments

@harrysolovay
Copy link

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
Copy link
Contributor

dvdplm commented Nov 15, 2021

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
Copy link
Author

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
Copy link
Contributor

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 paritytech/scale-info#72, which has been languishing on my todo list to review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants