Extend deployment.ts format

[peetzweg]

As of now the deployment.ts format is very basic

export const address = '5Ga8H7rtX66J3fn754cnTX1ZfCxZxwxzaZuqy5mfTRAfifQi'
export const blockNumber = 1

But this is not very future proof as this does not allow for the following things:

• indicate which contract it belongs to, just indicated by file path,
• does not give you information about which version of the contract it belongs to,
• does not keep track of multiple deployemnts of the same contract.

A new format will have trade offs but I think solving the mentioned issues with this format will proof itself handy for longer lasting production dapps. Upgrades of contracts happen, same as multiple deployments of the same contract on a single chain.

We could get some inspiration from this plugin from hardhat or whatever foundry is doing right now. 🤔

https://github.com/wighawag/hardhat-deploy

https://github.com/wighawag/forge-deploy

[wottpal]

Generally very open for more suggestions around this. Do you have a concrete new format in mind? Should this maybe even merged with the metadata.json file at some point (so far I liked it to have them separate). 🤔

indicate which contract it belongs to, just indicated by file path,

Should be an easy one, we could add an export for the contract name as well. Wdyt?

does not give you information about which version of the contract it belongs to,

Afaik, there is no "native" contract versioning for ink! contracts? Or maybe I miss something here, where should the version be pulled from? The name.contract metadata bundle itself has no version, right? I think this should be integrated there first.

does not keep track of multiple deployemnts of the same contract.

This is by design actually, to apply flexible .gitignores to e.g. development chains or intermediate test deployments. It's also done the same way by e.g. forge-deploy you've linked (for the very same reason). But open for all kind of concrete suggestions here. – I just want to avoid "multiple formats" (e.g. one for localhost which can be gitignored, and another one with all other addresses as this would feel like it adds more complexity than value).