Description
The Makefile and justfile both provide dev targets, and rust-toolchain.toml pins the Rust version (#32), but there's no single command a new contributor can run to check whether their local Rust, Node, and Soroban CLI versions all match what the project expects before they start debugging confusing build failures.
This is repository-level tooling, configuration, or process rather than application code, but that doesn't make it lower stakes: onboarding friction, unclear ownership, and process gaps are consistently what determines whether a project with this much surface area (two contract trees, two backend trees, two frontend apps, a static dashboard, and an active external contributor program) stays maintainable as it grows or slowly accumulates inconsistency that nobody has the full context to untangle.
Given that this repository is actively recruiting outside contributors through the Stellar Wave bounty program (this issue included), the quality of its repository-level scaffolding, from CONTRIBUTING.md to CODEOWNERS to its issue and PR templates, has a direct and measurable effect on how many contributors are able to land a change successfully on their first attempt versus giving up in the setup phase.
Requirements and context
- Add a
make doctor (and just doctor) target checking rustc --version, node --version, and soroban --version against expected ranges
Suggested execution
- Fork the repo and create a branch
git checkout -b chore/makefile-doctor-target
- Implement changes
- Test and commit
- Run
make doctor locally and confirm it reports mismatches clearly
Example commit message
chore: add doctor target for toolchain version validation
Guidelines
- Assignment required before starting
- PR description must include:
Closes #[issue_id]
- Keep PR description professional and detailed
Description
The
Makefileandjustfileboth provide dev targets, andrust-toolchain.tomlpins the Rust version (#32), but there's no single command a new contributor can run to check whether their local Rust, Node, and Soroban CLI versions all match what the project expects before they start debugging confusing build failures.This is repository-level tooling, configuration, or process rather than application code, but that doesn't make it lower stakes: onboarding friction, unclear ownership, and process gaps are consistently what determines whether a project with this much surface area (two contract trees, two backend trees, two frontend apps, a static dashboard, and an active external contributor program) stays maintainable as it grows or slowly accumulates inconsistency that nobody has the full context to untangle.
Given that this repository is actively recruiting outside contributors through the Stellar Wave bounty program (this issue included), the quality of its repository-level scaffolding, from
CONTRIBUTING.mdtoCODEOWNERSto its issue and PR templates, has a direct and measurable effect on how many contributors are able to land a change successfully on their first attempt versus giving up in the setup phase.Requirements and context
make doctor(andjust doctor) target checkingrustc --version,node --version, andsoroban --versionagainst expected rangesSuggested execution
Makefileand mirror it injustfile(chore: add Makefile targets for common dev tasks #29)make doctorlocally and confirm it reports mismatches clearlyExample commit message
chore: add doctor target for toolchain version validationGuidelines
Closes #[issue_id]