As a CDK author and Azle developer, I want to import the automatically generated IDL objects so that I can use them in Azle

[lastmjs]

Is your feature request related to a problem? Please describe.

Here is the context and discussion: https://forum.dfinity.org/t/automatic-javascript-idl-generation-from-candid/32692

I would like the automatically generated IDL objects (like from dfx generate) to be exported from their module so that we can import them and use them across Azle APIs. Azle's 1.0-bound syntax uses @dfinity/candid IDL objects to handle Candid serialization and deserialization. Tools like dfx generate make it easy to obtain these IDL objects for arbitrary canisters. But the generated code does not export these objects, so devs cannot currently make automatic use of these objects.

Describe the solution you'd like

Just export these objects from the generated code. They are currently not exported and stuck within a function scope I believe. Just export them with their current names.

Describe alternatives you've considered

Alternatives are to write these objects by hand, or manually edit the generated code, or write a tool that manipulates the code...the most ideal straight-forward and probably simplest solution is to just export these objects. They already exist, we just need them exported.

Additional context

Here is the context and discussion: https://forum.dfinity.org/t/automatic-javascript-idl-generation-from-candid/32692

[chenyan-dfinity]

It should be relatively easy to export the objects as discussed on the forum, but it requires some code duplication. We will have some internal discussion to see if we can do this more cleanly.

I think the quickest for now is to fork the candid_parser code base and apply this duplication. Can you do that?

[lastmjs]

I think the quickest for now is to fork the candid_parser code base and apply this duplication. Can you do that?

We really want to avoid using or asking our users to use non-upstreamed tools right now. We're trying to take Azle to 1.0 and we want devs to have access to this functionality with the upstreamed tools as far as possible.

[lastmjs]

Can you do that?

Do you want me to do the PR? You'll accept it with the duplication?

[chenyan-dfinity]

That works for me. We can improve it later.

[lastmjs]

I've got the exporting working pretty well for the JavaScript. But I have run into another problem.

I really want the bindings generated to have the JavaScript runtime values and the TypeScript types all in one file. This makes a very nice developer experience as the developer can import one name (say canister_info_args) and it will work as a value or as a type, without requiring two separate imports from two separate files and having to create separate names for the types and for the values.

I'm working on adding a new --target ts-js.

What do you think?

[chenyan-dfinity]

Does it work that you just concatenate the two generated files? If you want something more specialized, note that you can implement your bindgen in a separate crate, then you have full control over what it generates.

[lastmjs]

You can't just concatenate the two files unfortunately, there are a couple tweaks that need to be made.

[lastmjs]

I have a draft PR up for some feedback: #575

I haven't written any automated tests for --target ts-js yet, but we have been using it to generate the combined TypeScript files with --target ts-js for the management canister, ICRC canisters, and ICP ledger canister in Azle.