Provide option to create a slim metadata files

[DoubleOTheven]

It would be nice to skip the documentation and extra fields inside of metadata.json. There are some cases where you will have multiple instances of a contract client in JavaScript, which loads the metadata. Making this as small as possible is good for production apps.

[DoubleOTheven]

Maybe a flag --abi or --slim?

[Gioyik]

@DoubleOTheven I would like to work in this issue. Could you please give me information about the extra fields that should be stripped from the metadata.json file generation with this new flag?

now, if you could check my understanding of the problem that would be great. Checking the project structure, I can see the metadata.json file is generated with the BuildCommand https://github.com/paritytech/cargo-contract/blob/master/crates/cargo-contract/src/cmd/build/mod.rs and that it accepts a set of parameters for the generation, so I am assuming the new flag value should be passed to this BuildCommand to let it know when it required to skip documentation and extra fields https://github.com/paritytech/cargo-contract/blob/master/crates/cargo-contract/src/cmd/build/mod.rs#L585. Maybe something might need to be changed here: https://github.com/paritytech/cargo-contract/blob/master/crates/cargo-contract/src/crate_metadata.rs, but it's just a quick look that I have done to understand the flow of the task.

Let me know if I am close or at least I am touching the main point of the issue, and if you have any information that could be useful.

[wottpal]

Agree with @DoubleOTheven that such a flag is needed (or even should be the default). @Gioyik I guess authors, storage, and docs keys are unnecessary in the frontend. Not sure about source (might be useful in some cases).

[wottpal]

Any updates on this or something that speaks against it? cc @cmichi

[wottpal]

Things that come to my mind:

• Whitespace JSON-optimization can sometimes easily shave-off half of the whole metadata size
• docs fields as mentioned by @DoubleOTheven
• source & contract objects at the top could easily be reduced
• Optionally (might need to be configurable):
  • storage fields are often not accessed directly by frontends
  • constructor functions are often not used by the frontend
  • A lot of frontends only use a very small share of all present events & messages, but this would need even more custom configuration

@jacogr Anything to add? What fields could be stripped from metadata/abi files w/o losing any functionality?

I get the feeling that this could be more of a small external tool than inside cargo-contract itself. Maybe even with a simple drag'n'drop minification UI and with checkboxes to what include/exclude. 🤷‍♂️