You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current README sitting at the project's root folder contains mostly design decisions and implementation details. This is quite useful for contributors to help them understand the project. However, this is not the case for consumers/users of the Hardhat plugin and Foundry library.
Include the appropriate documentation targeting final users in this README. This should include basic instructions on how to use both solutions, and any configuration necessary to make it work. The PR1 includes some documentation regarding the Foundry library.
One possible solution could be to structure the design docs as following2
docs/README.md - general approach that we've laid out mostly on the README in terms of intercepting calls, system contracts, HTS tokens that support ERCs, etc.
docs/storage.md - more details and structure to the storage methodology also laid out in the README.
docs/hardhat-forking.md - the specific Hardhat approach. The sequence diagram in the README belongs here.
docs/foundry-forking.md - the specific Foundry approach. Explain how we use the same base contract to reuse behavior and storage layout, but we provide the actual data from Mirror Node calls within the EVM1.
If splitting up this design docs becomes problematic due to how interleaved both solutions are, we could have a single DESIGN.md sitting at the root folder containing all of it.
The current
README
sitting at the project's root folder contains mostly design decisions and implementation details. This is quite useful for contributors to help them understand the project. However, this is not the case for consumers/users of the Hardhat plugin and Foundry library.Include the appropriate documentation targeting final users in this
README
. This should include basic instructions on how to use both solutions, and any configuration necessary to make it work. The PR1 includes some documentation regarding the Foundry library.One possible solution could be to structure the design docs as following2
docs/README.md
- general approach that we've laid out mostly on theREADME
in terms of intercepting calls, system contracts, HTS tokens that support ERCs, etc.docs/storage.md
- more details and structure to the storage methodology also laid out in theREADME
.docs/hardhat-forking.md
- the specific Hardhat approach. The sequence diagram in theREADME
belongs here.docs/foundry-forking.md
- the specific Foundry approach. Explain how we use the same base contract to reuse behavior and storage layout, but we provide the actual data from Mirror Node calls within the EVM1.If splitting up this design docs becomes problematic due to how interleaved both solutions are, we could have a single
DESIGN.md
sitting at the root folder containing all of it.Footnotes
https://github.com/hashgraph/hedera-forking/pull/105 ↩ ↩2
Thanks @Nana-EC for the suggestion. ↩
The text was updated successfully, but these errors were encountered: