Skip to content

Remove the submodule-era residue — dead foundry.lock, .gitmodules and lib/ references in a repo with no submodules #40

Description

@thedavidmeister

What foundry.lock is

foundry.lock is Foundry's git submodule lockfile. It records the commit each dependency vendored under lib/ is pinned to, so forge install / forge update can restore identical submodule revisions. It is only meaningful in a repo that vendors dependencies as git submodules.

Why it is dead in this repo

There is no .gitmodules and no lib/ directory on main, and git ls-files --stage on a fresh clone reports zero gitlinks (mode 160000). Dependencies come from soldeer: foundry.toml sets libs = ["dependencies"], and soldeer.lock is the live lockfile for the two packages that land under dependencies/:

  • forge-std 1.16.1
  • rain-sol-codegen 0.1.6

foundry.lock meanwhile still carries 1 submodule pin, for a lib/ path that does not exist in the tree:

{
  "lib/forge-std": {

      "rev": "1801b0541f4fda118a10798fd3486bb7051c5dd6"
  }
}

The two contradict each other. 1801b0541f4fda118a10798fd3486bb7051c5dd6 is the v1.14.0 tag of forge-std; the build actually uses 1.16.1, per both foundry.toml [dependencies] and soldeer.lock. Nothing reconciles them, because nothing reads the foundry.lock side.

Submodules also cannot come back: rainix CI runs a no-submodules check that fails on a root .gitmodules or any committed gitlink, so there is no future in which this pin becomes live again.

It is not silent

forge build emits one warning per entry in this file — verified on a fresh clone of main in the pinned rainix#sol-shell (forge 1.7.2-nightly, 43923a4):

Warning: Dependency 'lib/forge-std' not found at expected path

Everything dangling in this repo

foundry.lock is not the only thing the submodule → soldeer migration left behind. Every reference below names a path that does not exist on main. All of it is one removal, not separate work.

The dead lockfile and its references

  • foundry.lock — the file itself
  • REUSE.toml line 15 — "foundry.lock", in the annotation path list
  • .soldeerignore line 18 — /foundry.lock

Submodule paths that no longer exist

  • REUSE.toml line 8 — ".gitmodules",. There is no .gitmodules in the tree and no gitlinks.
  • .soldeerignore line 7 — .gitmodules, same absent file.
  • .soldeerignore line 20 — /lib. There is no lib/ directory. foundry.toml sets libs = ["dependencies"], so forge resolves everything under dependencies/ and never creates lib/.

None of these can come back, for the no-submodules reason above.

Other dangling references found while checking

  • REUSE.toml line 5 — ".gas-snapshot",. There is no .gas-snapshot here, and .gitignore does not list it either, so nothing in the tree or in CI produces one that the annotation could cover.
  • .soldeerignore line 3 — .gas-snapshot, same absent file.
  • .soldeerignore line 25 — /target. This repo has no Rust: no Cargo.toml, no crates/, and target is not in .gitignore. Nothing here produces a target/.

Deliberately not in scope. .soldeerignore also names .DS_Store, .vscode, .pre-commit-config.yaml and the build/publish outputs (/out, /cache, /dependencies, /docs). Those are absent from a clean checkout by design — OS junk, local developer files, or artifacts generated at forge soldeer install / forge build / devShell-entry time and therefore present when soldeer push runs. They are correct ignores and must stay.

Nothing else references any of it. .github/workflows/, flake.nix, foundry.toml, remappings.txt, .gitignore, script/, audit/, slither.config.json, CLAUDE.md and README.md were grepped and are clean — CLAUDE.md describes the soldeer layout correctly and says nothing about submodules.

No single one of these references blocks its own deletion — reuse lint (the rainix-sol legal job) tolerates annotation paths that do not exist, and a .soldeerignore line for a nonexistent path is a no-op. They are listed so this cleanup lands complete instead of repeating the half-finished pass described below.

Context

This is the tail of an unfinished migration, not a convention.

Pass 1 of this sweep covered the 17 repos that consume rain.solmem via soldeer. Every one of them carried residue, and each now has its own issue. This is pass 2: a further 17 rainlanguage repos with the same dangling entries — rain.deploy, rain.sol.codegen, rain.factory, rainix, rain.factory.deploy, rain.vats, rain.math.saturating, rain.math.binary, rain.pyth, rain.vats.flare, rain.sol.binmaskflag, rain.math.fixedpoint, rain.metadata, rain.verify.interface, rain.lib.typecast, rain.lib.hash, raindex.interface — of which ten still carry a dead foundry.lock: rain.deploy, rain.sol.codegen, rain.math.saturating, rain.math.binary, rain.sol.binmaskflag, rain.math.fixedpoint, rain.metadata, rain.lib.typecast, rain.lib.hash, raindex.interface. This issue covers rain.deploy only.

Deleting the file was never the whole job. The references outlive it silently, because not one of them fails anything.

rainlanguage/flow and rainlanguage/rain.tier.interface genuinely still use git submodules — live gitlinks, verified — so their .gitmodules and lib/ entries are correct and must be left alone.

This is configuration only. No Solidity source, no deployed bytecode and no audited artifact changes.

Done when

  • foundry.lock deleted
  • REUSE.toml lines 5, 8 and 15 removed
  • .soldeerignore lines 3, 7, 18, 20 and 25 removed
  • forge build no longer emits Dependency '...' not found at expected path
  • no reference to .gitmodules, lib/ or foundry.lock remains anywhere in the tree outside dependencies/
  • CI green (rainix-sol test / static / legal)

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