NomicFoundation
Support `Settings` (a.k.a. Input JSON Description) in `@nomiclabs/hardhat-vyper`
Describe the feature
The @nomiclabs/hardhat-vyper package only supports currently the setting of Vyper version(s): https://github.com/NomicFoundation/hardhat/blob/ef4a94dfc49585b031faf75d5ef49bc438d43091/packages/hardhat-vyper/src/types.ts#L3-L9
It would be very convenient to have an option to at least set the evmVersion, as since Vyper 0.3.8 (latest version is 0.3.10) the evmVersion is set to shanghai and people might be interested to deploy on e.g. Optimism with these versions but can natively since PUSH0 is not yet supported.
The full Input JSON Description can be found here:
{
// Required: Source code language. Must be set to "Vyper".
"language": "Vyper",
// Required
// Source codes given here will be compiled.
"sources": {
"contracts/foo.vy": {
// Optional: keccak256 hash of the source file
"keccak256": "0x234...",
// Required: literal contents of the source file
"content": "@external\ndef foo() -> bool:\n return True"
}
},
// Optional
// Interfaces given here are made available for import by the sources
// that are compiled. If the suffix is ".vy", the compiler will expect
// a contract-as-interface using proper Vyper syntax. If the suffix is
// "abi" the compiler will expect an ABI object.
"interfaces": {
"contracts/bar.vy": {
"content": ""
},
"contracts/baz.json": {
"abi": []
}
},
// Optional
"settings": {
"evmVersion": "shanghai", // EVM version to compile for. Can be istanbul, berlin, paris, shanghai (default) or cancun (experimental!).
// optional, optimization mode
// defaults to "gas". can be one of "gas", "codesize", "none",
// false and true (the last two are for backwards compatibility).
"optimize": "gas",
// optional, whether or not the bytecode should include Vyper's signature
// defaults to true
"bytecodeMetadata": true,
// The following is used to select desired outputs based on file names.
// File names are given as keys, a star as a file name matches all files.
// Outputs can also follow the Solidity format where second level keys
// denoting contract names - all 2nd level outputs are applied to the file.
//
// To select all possible compiler outputs: "outputSelection: { '*': ["*"] }"
// Note that this might slow down the compilation process needlessly.
//
// The available output types are as follows:
//
// abi - The contract ABI
// ast - Abstract syntax tree
// interface - Derived interface of the contract, in proper Vyper syntax
// ir - intermediate representation of the code
// userdoc - Natspec user documentation
// devdoc - Natspec developer documentation
// evm.bytecode.object - Bytecode object
// evm.bytecode.opcodes - Opcodes list
// evm.deployedBytecode.object - Deployed bytecode object
// evm.deployedBytecode.opcodes - Deployed opcodes list
// evm.deployedBytecode.sourceMap - Deployed source mapping (useful for debugging)
// evm.methodIdentifiers - The list of function hashes
//
// Using `evm`, `evm.bytecode`, etc. will select every target part of that output.
// Additionally, `*` can be used as a wildcard to request everything.
//
"outputSelection": {
"*": ["evm.bytecode", "abi"], // Enable the abi and bytecode outputs for every single contract
"contracts/foo.vy": ["ast"] // Enable the ast output for contracts/foo.vy
}
}
}
Note that the "optimize" inputs where modified in the latest
0.3.10version, as well as there is ongoing discussion on how to support the standard Input JSON in the future. But theevmVersionis important to have in anyway.
Search terms
vyper, evmVersion
Just as an add-on note, since 0.3.10 you can specify the evmVersion via the pragma statement, so this can be used as a workaround for now as long as you use the latest Vyper version. You can see the configuration details in my 🐍 snekmate v0.0.3 release:
