Include bytecode files in export
tomasmik opened this issue · 8 comments
Hi, I was wondering would it be possible to also have a flag to also generate files with bytecode for the contract? From what I understand they already exist in the artifacts.
Such a feature would save some time when generating abi files to be used in for example bindings for golang
This plugin extracts contract ABI fields from artifacts and exports them as top-level JSON objects in their own files. Additional data could be included in one of two ways: (1) nesting all data, including ABI, within the same JSON object; (2) creating separate output files.
The first will not work, because it breaks the API and, in my opinion, defeats the purpose of exporting data from the artifacts in the first place.
The second might work, but I think would be more suitable as its own plugin. If you help me to understand the use case for bytecode export a bit better, I will consider releasing that. (Alternatively, you could probably fork this repository and do it yourself by changing only a couple of lines.)
The second might work, but I think would be more suitable as its own plugin. If you help me to understand the use case for bytecode export a bit better, I will consider releasing that. (Alternatively, you could probably fork this repository and do it yourself by changing only a couple of lines.)
I have no problem with forking and making my own changes, just though I would throw it out as an idea.
My main problem is that abi files only are not enough to generate bindings and have the DeployX functions. To get "full" bindings which you can use to deploy the contract you need both abi and bytecode.
Take a look here under section: Deploying contracts to Ethereum
I suppose my question is why it would be more convenient to export this data rather than just use use the artifacts. My reasoning for exporting ABIs is that they can be added to version control in a contract repositiory, and imported as a dependency into a dapp repository. That way the dapp repositiory does not have to handle compilation. Would a similar workflow be useful for generating the bindings you need? Or would it be better to incorporate the whole process into a plugin?
Would a similar workflow be useful for generating the bindings you need? Or would it be better to incorporate the whole process into a plugin?
Yes. It's a bit more convenient to have two different files for bytecode and abi in version control for when you want to generate bindings. You can sort of kind of do it from a single artifact file, but you also bring unneeded things with it.
If you dont see this as a beneficial flag for this specific package, I have no problem wtih forking and making my own changes though.
Yes, I think for now forking is best. I might consider releasing a generalized plugin for exporting any combination of data from artifacts, but not at the moment. Let me know if you have any issues modifying the code.
This may be useful! I am building a hardhat plugin that requires a contract bytecode in the integration tests but I would like to maintain the contracts in a separate package.
Probably it makes sense to have its own dedicated repo, but for my use case, I just need the bytecode files mirrored in a different directory. With a couple of lines, we could easily support it.
Hello ! Would have been amazing to have this feature supported!
Bytecode exporter plugin released: https://github.com/solidstate-network/hardhat-bytecode-exporter