Migrate dependency management from git submodules to soldeer
This repo is a level-1 leaf in the Rain dependency tree (depends only on external forge-std, no other Rain repos). Migrating it first unblocks the soldeer migration of every Rain repo that depends on it.
Why
- Smaller clones — soldeer fetches archives, not full git history of each dep.
- Cleaner versioning — semver lock via
soldeer.lock rather than tracking arbitrary commit SHAs across .gitmodules + foundry.lock.
- First-class foundry support (
forge soldeer install).
- CI simpler: no
submodules: recursive checkout.
- Removes today's silent version drift across the wider Rain dep tree (e.g.
forge-std is at 3 different SHAs and rain.solmem at 2 different SHAs across rain.math.float's transitive submodules).
What changes
- Delete
.gitmodules and the lib/ submodule pointers.
- Replace
foundry.toml remappings with a [soldeer] / [dependencies] section.
- Add
soldeer.lock (committed) pinning resolved versions.
- Update CI: drop
submodules: recursive from actions/checkout@v4, add forge soldeer install step.
- Publish this repo to the soldeer registry (https://soldeer.xyz) so dependents can consume it.
Bytecode-reproducibility check (must pass before merge)
For repos with deterministic on-chain deployments, confirm keccak256(creationCode) of any contract compiled from this source is identical pre- and post-migration on the same source revision. Any drift means the soldeer-fetched archive differs byte-for-byte from the git-tracked version (likely line-ending normalization or .gitignored files); resolve before merging.
For rain.deploy specifically this is critical — it ships the Zoltu factory consumers across the Rain ecosystem.
Sequencing
This is part of a wider migration tracked at rainlanguage/rain.math.float#194 ; see the full topological order there. Level-1 leaves can be migrated in parallel.
Out of scope
- Switching off forge entirely.
- Changing any deterministic deploy address intentionally — any change must be unintentional and verified zero-impact.
Migrate dependency management from git submodules to soldeer
This repo is a level-1 leaf in the Rain dependency tree (depends only on external
forge-std, no other Rain repos). Migrating it first unblocks the soldeer migration of every Rain repo that depends on it.Why
soldeer.lockrather than tracking arbitrary commit SHAs across.gitmodules+foundry.lock.forge soldeer install).submodules: recursivecheckout.forge-stdis at 3 different SHAs andrain.solmemat 2 different SHAs acrossrain.math.float's transitive submodules).What changes
.gitmodulesand thelib/submodule pointers.foundry.tomlremappingswith a[soldeer]/[dependencies]section.soldeer.lock(committed) pinning resolved versions.submodules: recursivefromactions/checkout@v4, addforge soldeer installstep.Bytecode-reproducibility check (must pass before merge)
For repos with deterministic on-chain deployments, confirm
keccak256(creationCode)of any contract compiled from this source is identical pre- and post-migration on the same source revision. Any drift means the soldeer-fetched archive differs byte-for-byte from the git-tracked version (likely line-ending normalization or.gitignoredfiles); resolve before merging.For
rain.deployspecifically this is critical — it ships the Zoltu factory consumers across the Rain ecosystem.Sequencing
This is part of a wider migration tracked at rainlanguage/rain.math.float#194 ; see the full topological order there. Level-1 leaves can be migrated in parallel.
Out of scope