@wighawag I understand your points and I think storing our information directly with the hardhat-deploy metadata could work.
However, building the functionality that would allow that kind of deep integration is beyond what we can tackle with our current resources, so I think it will be easier to simply expose the storage layout functionality for you to integrate those in hardhat-deploy as you see fit.
I’m still concerned about us eventually modifying the format of the metadata that we expect, but we can figure out how to allow hardhat-deploy to migrate to that new format. (This is just a precaution, there are no concrete plans, and I don’t expect it will happen often at all.)
Here are some pointers to what we have now, and we can settle on requirements for what hardhat-deploy needs from our library.
The storage extraction and comparison logic is in our
Storage Layout Type
We have a
StorageLayout type. It’s similar to what the compiler emits with the
storageLayout output selection, but not the same, so you need to use our own layout extraction routine. We do this to support older Solidity versions where the compiler output selection isn’t present. The differences with the layout generated by solc are quite small… but we’re not keeping track of these differences, and things might change.
The storage layout is extracted from the AST. The function
extractStorageLayout works on an AST node for a contract definition, and some additional AST helpers that we obtain based on the compiler output.
This function should be wrapped in a higher level function that takes the solc input and output JSON, so that you don’t have to concern yourself with creating these AST helpers.
Comparison between an original and an upgraded storage layout happens in a class called
StorageLayoutComparator, through its
compareLayouts function. This function returns an instance of
LayoutCompatibilityReport, which can then be printed through its
We use a higher level wrapper around this class that is called
assertStorageUpgradeSafe. The wrapper will throw an exception if the layouts are not compatible, and print the error report.
If you don’t want this to throw an exception, you could use the comparator class directly, but we’d need to adjust a few things because the storage layout has to be “expanded” before it can be passed to the comparator.
If you want to take a look at these things, we can define what else we have to add for hardhat-deploy to be able to use this.
From what I can tell, we need:
- A higher level function to extract storage layout from solc input and output JSON.
- Adjust the input to the
StorageLayoutComparator so that it is the plain storage layout that was extracted previously without modifications.