-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: move cheatcodes from forge-std to forge #3782
Comments
This migration could also be an opportunity to introduce a few breaking changes to cheats, such as: |
I've done some testing and just want to share the results:
I don't really know much about how solc deals with dependecies and which of those are getting compiled more often for external projects, I think it makes sense to try removing console libs or mocks for some big codebases to see how it would affect compilation time. |
Component
Forge
Describe the feature you would like
Right now the forge
vm
defines many cheat codes, andforge-std
builds on these with many additional helpers. The distinction between the two is fairly arbitrary (though that hasn't been much of a problem, just occasional discussions about where a feature should live, e.g. #3732 (comment))The suggestion in this issue is to move as many of the forge-std cheats out of solidity and directly into forge in rust. The main rationale is that the
src/
dir of forge-std takes ~3-4s to compile on my machine, so the more we can remove from it the faster it will be for users to compile/run their test suites (since native cheats add no compilation overhead, but solidity ones do), and compilation speed is a common bottleneck.Of course, this doesn't mean you'd save the full 4s in testing, since if you're not using all of forge-std you aren't compiling/optimizing all of it. So true benefit may be smaller—a rough benchmark here is take a few repos, replace all forge-std functions with empty implementations, and compare build times before and after those changes. This should underestimate the savings (since there are still more functions to compile, even though they have empty implementations)
Smaller benefits are:
vm.*()
, instead of the current split between somevm.*()
methods for native cheats and*()
for forge-std cheats (related to discussion in Same synthax fordeal
#3322 (comment))vm.assertEq()
andvm.failed()
to remove the need for ds-test as a dependency which is niceThere would still be some things we want to keep in forge-std, such as:
vm
variable/interface in all tests by simply inheriting fromTest
/Script
, and keeping the safe vs. unsafe cheats distinction for scriptsstdJson
lib for better UX (edit: now I can't recall why I thought these shouldn't be native cheats)Additional context
No response
The text was updated successfully, but these errors were encountered: