Include bytecode files in export about hardhat-abi-exporter HOT 8 CLOSED

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.

from hardhat-abi-exporter.

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.)

from hardhat-abi-exporter.

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

from hardhat-abi-exporter.

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?

from hardhat-abi-exporter.

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.

from hardhat-abi-exporter.

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.

from hardhat-abi-exporter.

Hello ! Would have been amazing to have this feature supported!

from hardhat-abi-exporter.

Bytecode exporter plugin released: https://github.com/solidstate-network/hardhat-bytecode-exporter

from hardhat-abi-exporter.