zerosnacks
zerosnacks
>introduce a basic lockfile `foundry.lock` that consists of a mapping from relative `lib_path` to `DepIdentifier`. This file is committed with every `forge install`. because we don't auto-commit anymore this is...
Would be great if this PR was accompanied by an update to the book to document the `forge update owner/dep@new-tag` behavior as it will be a common question
Good call, I think it is worth considering how to make this lockfile format future proof inside of the context of this PR. I would like to avoid introducing optional...
After reflecting, imo we ship the lockfile as is. If we do decide to make a breaking change and start applying a versioning scheme we can introduce a `version` field...
Hi @zzh1996 thanks for your suggestion! I like the idea of making `forge script` behave much more like a database migration than a one-off bash script. This also ties into...
This also ties into `--verify`, we need to make sure that if the contracts are already deployed we do attempt verifying