Choose/create an artifacts format

[alcuadrado]

We are currently generating a slightly modified subset of Truffle's artifacts. This is implemented this was because we are Truffle Contracts, but we will remove it asap.

We should choose another artifacts format if there's a good one, or design our own.

This issue is specially important, and we want to have as much feedback as possible.

At the very least artifacts should allow linking, deploying and using already-deployed contracts. But we may also want to provide some extra functionality.

[jdkanani]

Would be great if buidler could include deployedByteCode, sourceMap, deployedSourceMap, sources and id (to map back to sources) :)

Is there any reason or benefit for not using truffle's artifact format?

[alcuadrado]

Truffle's artifact format is both incomplete and bloated. It doesn't include linkReferences, which makes linking libraries unnecessarily tricky, and it includes many things that are not used.

I'm not sure if the artifact is the right place to store information about deployments. I haven't came up with a clear alternative, but I think something better could be done.

I'd love to include source maps, but I need to play with tools that uses them first, to figure out what is the right way of doing it. Can you point me to any tool with source maps support?

[federicobond]

evmlab has some source map support. I'm not a fan of including deployment info either. I think that requires a separate format.

[jdkanani]

My mistake. I don't want deployment details in artifacts, but runtimeBytecode and runtimeSourceMap, I think truffle calls it deployedBytecode.

@alcuadrado sol-trace also uses source-map to trace revert opcode.

[shrugs]

I like the separation between deployment info and other artifact information. zos-cli places deployment info in the root of the project in another .json file, which I prefer. I'd like to be able to completely nuke my artifacts directory and re-instantiate it by compiling without losing any information.