The published rain-sol-codegen package ships no dependency metadata, and the README never names the forge-std version its imports require

[thedavidmeister]

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.11 zip: 18 entries, none of which is foundry.toml,
  soldeer.lock or remappings.txt.
• 3 of 3 src/lib/*.sol files 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.7 also ships no foundry.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.

[thedavidmeister]

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:

Source "forge-std-1.16.1/src/Vm.sol" not found

which maps one-to-one onto forge soldeer install forge-std~1.16.1. The
compiler names the version because the version is in the prefix. rain.deploy,
the live consumer, carries exactly the two remappings this produces:

forge-std-1.16.1/=dependencies/forge-std-1.16.1/
rain-sol-codegen-0.1.6/=dependencies/rain-sol-codegen-0.1.6/

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-wide
convention (verified in rain.math.float, rain.deploy, rain.interpreter and
rain.metadata, all false), 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.