Skip to content

Migrate dependency management from git submodules to soldeer #194

Description

@thedavidmeister

Migrate dependency management from git submodules to soldeer

The repo currently uses 6 git submodules (forge-std, rain.string, rain.datacontract, rain.math.fixedpoint, rain.deploy, rain.sol.codegen) plus an openzeppelin-contracts submodule under rain.math.fixedpoint/lib/. Switch to soldeer for dependency management.

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).
  • Easier transitive resolution; today each indirect dep has to be added explicitly as a submodule.
  • CI simpler: no submodules: recursive checkout.

What changes

  1. Delete .gitmodules. Remove lib/ from version control (or keep it as the soldeer install target).
  2. Replace foundry.toml's remappings = [...] with a [soldeer] and/or [dependencies] section.
  3. Add soldeer.lock (committed) that pins resolved versions.
  4. Add forge soldeer install to every CI job that builds (rainix.yaml, manual-sol-artifacts.yaml, etc.) and drop submodules: recursive from actions/checkout@v4.
  5. nix develop shell needs to provide a soldeer-aware forge (current nix develop already does, modulo flake.lock bumps).

Per-dependency decisions

Each rain.* dep needs to be either:

  • Published to the soldeer registry (https://soldeer.xyz) — clean semver consumption.
  • Declared as a git-source dependency in foundry.toml — rain.deploy = { url = "...", ref = "<sha>" }. Equivalent to submodules with different syntax; doesn't gain semver benefits.

Recommendation: publish rain.* to soldeer first; consume via published versions in this repo.

Bytecode-reproducibility check (must pass before merge)

The Zoltu deterministic deploy address is a function of creation code, which transitively depends on every byte of every dependency. Confirm keccak256(type(DecimalFloat).creationCode) is identical before and after the migration on the same source revision; if it shifts, LibDecimalFloatDeploy.ZOLTU_DEPLOYED_DECIMAL_FLOAT_ADDRESS and the contract codehash constants must be regenerated and a redeploy triggered.

Same check for LibDecimalFloatDeploy.combinedTables() initcode (log tables data contract).

Open questions to resolve before starting

  • Which rain.* deps are already published to soldeer? Which need to be published as part of this migration?
  • Are downstream consumers of rain.math.float on soldeer, submodules, or both?
  • Does rain.deploy itself need to migrate first (it uses submodules today per its CLAUDE.md)?

Out of scope

  • Switching off forge entirely.
  • Changing the deterministic deploy address intentionally (any change must be unintentional and verified zero-impact).

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions