Repository navigation
The published rain-sol-codegen package ships no dependency metadata, and the README never names the forge-std version its imports require #82
Description
Audit scope: whole-repo, commit 7aa85a4
Dimension 3 (documentation) · severity medium
Where
- published
rain-sol-codegen~0.1.11 README.md:23-29(the Install section)
Problem
The 0.1.11 zip has 18 entries: no foundry.toml, no soldeer.lock, no
remappings.txt. All three libraries hard-import forge-std by an exact,
version-pinned prefix — src/lib/LibCodeGen.sol:5, src/lib/LibFs.sol:5 and
src/lib/LibHexString.sol:5 are each:
import {Vm} from "forge-std-1.16.1/src/Vm.sol";So a consumer following the README's Install section gets a package that cannot
compile the moment they import anything from it, and the README never names
forge-std, its version, or the prefix. The Install section is two lines of
forge soldeer install rain-sol-codegen~<version> and nothing else — no
prerequisite is stated anywhere in the file.
Evidence measured
- published
0.1.11zip: 18 entries, none of which isfoundry.toml,
soldeer.lockorremappings.txt. - 3 of 3
src/lib/*.solfiles import the literal prefix
forge-std-1.16.1/src/Vm.sol; there is no remapping shipped that could
redirect it. - sibling package
rain-math-float~0.1.7also ships nofoundry.toml.
Proposed fix
A sibling (rain-math-float~0.1.7) ships no foundry.toml either, so that is
org convention and the package is not where this gets fixed. The README is:
state the forge-std version and import prefix the package requires, as an
install prerequisite.
Related
#76 — the published
package is never compiled as published. A CI job that builds the filtered tree
would also be the thing that keeps this README prerequisite honest, since it has
to supply forge-std to build at all.
Activity
Move the README/foundry.toml pin check out of forge test to rainix#317
thedavidmeister commentedon Aug 17, 2026
Closing: not a defect in this repo. What this asks for is soldeer's
documentation, and the requirement it says is undocumented is already carried by
the source in a form that cannot go stale.
The premise does not hold. The issue says a consumer following the Install
section "gets a package that cannot compile the moment they import anything from
it". What they actually get is a self-solving error. Soldeer writes versioned
remapping prefixes by default, so the version-pinned import is the dependency
declaration:
which maps one-to-one onto
forge soldeer install forge-std~1.16.1. Thecompiler names the version because the version is in the prefix.
rain.deploy,the live consumer, carries exactly the two remappings this produces:
And the fix asked for is third-party documentation. How soldeer resolves
dependencies, what remappings it writes and how a missing prefix fails are
properties of soldeer, identical for every package it serves. Documenting them
in this README makes this repo one of N stale copies of soldeer's own docs.
Compare: shared CI lives in rainix's reusables rather than each consumer, and
the mutation-scan ledger format lives in the skill that writes it rather than
each repo that holds one. Same rule.
The one adjacent fact that is not soldeer-generic — that this org sets
recursive_deps = false, so dependency resolution is flat — is an org-wideconvention (verified in
rain.math.float,rain.deploy,rain.interpreterandrain.metadata, allfalse), not something this repo's README owns.PR #117 is closed with the same reasoning. #76 (the published package is never
compiled as published) is a separate, live issue and is unaffected.