Feature request: anchor keys sync should export the program id as a const in the TypeScript file

[beeman]

Currently, there's no easy way to get the program id from an Anchor program in TypeScript. The developer generally manually copies the id over to their app, which is not ideal.

It would be great if the keys sync command could automatically export the program id in the TypeScript file.

So when running anchor keys sync, next to the program id being synced up in lib.rs and Anchor.yaml, it would also add a line to target/types/<program_name>.ts:

export const PROGRAM_ID = 'abc...xyz';

[acheroncrypto]

We put program id in the IDL after the deploy step and you can access it via program.idl.metadata.address, though I agree we should make this easier and more intuitive.

[beeman]

We put program id in the IDL after the deploy step and you can access it via program.idl.metadata.address, though I agree we should make this easier and more intuitive.

Thanks for the quick reply.

I did look at using the property from the IDL but there I see 2 downsides to this:

• it can be tricky to read the JSON file using frontend tooling
• the property gets removed when you run anchor build

I'm happy to give a shot at implementing this but I'm pretty much a Rust noob so any guidance is welcome!

[acheroncrypto]

the property gets removed when you run anchor build

Yeah, I think this is a problem because we only add the metadata.address field after anchor deploy. What would you think of adding it after anchor build instead?

[beeman]

What would you think of adding it after anchor build instead?

I think that makes a lot of sense.

Ideally both in metadata.address in the json file and exported as a variable next to the export const IDL statement.

[acheroncrypto]

The IDL spec now requires address field, so there is no longer a need to export the program id.

Added in #2824.

[beeman]

• it can be tricky to read the JSON file using frontend tooling

Very excited to see the new IDL format, great stuff!

And while it does serve a part of the issue, there's still this point:

• it can be tricky to read the JSON file using frontend tooling

Ideally, we can directly import a symbol like const PROGRAM_ID = 'X' from the generated TypeScript code, without having to rely on any logic for parsing the JSON file.

[acheroncrypto]

it can be tricky to read the JSON file using frontend tooling

Please explain why it is tricky to read JavaScript Object Notation using frontend tooling when the language has first-class support for it?

Ideally, we can directly import a symbol like const PROGRAM_ID = 'X' from the generated TypeScript code, without having to rely on any logic for parsing the JSON file.

Is the "parsing logic" that we rely on JSON.parse? You don't even need to do it most of the time since bundlers parse JSON imports automatically.

[beeman]

it can be tricky to read the JSON file using frontend tooling

Please explain why it is tricky to read JavaScript Object Notation using frontend tooling when the language has first-class support for it?

Ideally, we can directly import a symbol like const PROGRAM_ID = 'X' from the generated TypeScript code, without having to rely on any logic for parsing the JSON file.

Is the "parsing logic" that we rely on JSON.parse? You don't even need to do it most of the time since bundlers parse JSON imports automatically.

Weirdly enough, the main issue is opening the actual file. Especially when this file is shipped in an npm package. Once read, parsing the json payload is easy.

Happy to provide a demo to convince you.

Any reason why not to export this as a common symbol? Is it really hard? Does its hurt in any other way?

I personally think it will make everybody's life easier.

[acheroncrypto]

Weirdly enough, the main issue is opening the actual file. Especially when this file is shipped in an npm package. Once read, parsing the json payload is easy.

Happy to provide a demo to convince you.

Just to be clear, it's a demo of how hard it is to open a JSON file in frontend using JS/TS? I certainly must be missing something and would be happy to see the problem.

Any reason why not to export this as a common symbol? Is it really hard? Does its hurt in any other way?

The reason is that, the address already exists in the IDL, which is already needed to interact with the program or pretty much any other functionality from the TS package. It is also not a type, which is why the IDL constant has also been removed.

[beeman]

While I was building the example I figured that it's probably a matter of enabling these TypeScript options:

This allows me to import it like so:

This way, it gets compiled and pushed to NPM like a proper symbol:

This allows consumers of my package to import the PROGRAM_ID, without having to worry about how my package handles this.

Thanks for putting me on the right path, this will now work great with the new IDL!

Coming to create-solana-dapp soon!