For crytic-compile Etherscan platform (contract's source code downloader), I noticed some downloaded sources rely on remappings (e.g for relative import paths like import "@openzeppelin/contracts/token/ERC20/ERC20.sol" inside the target contracts). Those compile fine while in-memory (when first initialized) but their output files cannot be easily again re-compiled from within the directory of downloads (crytic-export). In simpler words - when crytic-compile first downloads source it compiles it fine, but when executed next time on Target.sol file within the downloaded directory it fails with File Not Found (because of remappings).
I did a cursory glance on Etherscan Platform Class and CompilationUnit Class and there is a remapping data available in the local scope of init functions, so I assume that during the crytic-compile run correct remapping data is available. Why not output it into .config file of some sort to the downloaded directory in process resolving the need for manually creating remappings? I also assume that remappings are correct if the contract compiles for the first time.
I do have a use case I am working on and I currently need to resort to secondary scripts manipulating directory structure or casting it directly to foundry leveraging framework's remapping organization to re-compile already once successfully compiled code. I would actually prefer to stay within crytic-compile and it's output directories - being able to run/initialize crytic-compile Target.sol {remappings:remappings.json} (both for cli and direct library use).
Is this something you would consider adding? Or, maybe I am missing some method for returning such data from CompilationUnit/SourceMapping? I think this would influence dev experience a lot if downloaded directory doesn't need to be re-processed manually
For crytic-compile
Etherscanplatform (contract's source code downloader), I noticed some downloaded sources rely on remappings (e.g for relative import paths likeimport "@openzeppelin/contracts/token/ERC20/ERC20.sol"inside the target contracts). Those compile fine while in-memory (when first initialized) but their output files cannot be easily again re-compiled from within the directory of downloads (crytic-export). In simpler words - when crytic-compile first downloads source it compiles it fine, but when executed next time on Target.sol file within the downloaded directory it fails withFile Not Found(because of remappings).I did a cursory glance on
EtherscanPlatform Class andCompilationUnitClass and there is a remapping data available in the local scope of init functions, so I assume that during the crytic-compile run correct remapping data is available. Why not output it into .config file of some sort to the downloaded directory in process resolving the need for manually creating remappings? I also assume that remappings are correct if the contract compiles for the first time.I do have a use case I am working on and I currently need to resort to secondary scripts manipulating directory structure or casting it directly to foundry leveraging framework's remapping organization to re-compile already once successfully compiled code. I would actually prefer to stay within crytic-compile and it's output directories - being able to run/initialize crytic-compile
Target.sol {remappings:remappings.json}(both for cli and direct library use).Is this something you would consider adding? Or, maybe I am missing some method for returning such data from CompilationUnit/SourceMapping? I think this would influence dev experience a lot if downloaded directory doesn't need to be re-processed manually