-
Notifications
You must be signed in to change notification settings - Fork 10
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
Comments
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? :) |
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 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 Curious to hear your thoughts! |
This was a usecase I had in mind when originally implementing "dogfooding" in Of course we now have paritytech/scale-info#72, which has been languishing on my todo list to review. |
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 (forMetaForm
)?The text was updated successfully, but these errors were encountered: