feat: Narrow typechain SealedBool/Uint/Address utype
#19
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In hardhat
typechain
runs directly after a hardhat compile task is run. The types forSealedBool
/SealedUint
/SealedAddress
generated bytypechain
look like this:However fhenix.js expects the type of SealedUint to have
utype
to be constrained to theutype
s associated with each Uint (0-5 for uint8-uint256). The narrowedutype
field allows us to statically convert aSealedUint
type into abigint
, and aSealedBool
type into abool
. This allowsfhenixsdk.unseal
to accurately infer the unsealed return types of a sealed output function. Without the narrowedutype
unseal does not correctly type the unsealed data. This PR performs a find and replace of the generated types and narrows them.For example:
All instances of
SealedUintStruct
andSealedUintStructOutput
(generated in typechains configuredoutDir
) with the narrowed versions (utype: bigint -> utype: 0 | 1 | 2 ...). This replacement step is already done in the frontend by overridingabitype
andviem
, and this PR adds the functionality to the hardhat side.NOTE: This is a pretty quick and dirty way of making this replacement, the alternatives are typescript interface declaration merging (wont work since the literals would be unioned with the existing type: 0 | 1 ... | 5 | bigint), or creating a custom
typechain
target which changes the internals of how the types are generated (time consuming and vendor locking).Screenshot of usage (from

fhenix-hardhat-example
)