Description
With two separate React frontends and their own package-lock.json files, dependency version drift between the two (e.g. different React or Vite major versions) could cause inconsistent behavior or bugs that only reproduce in one app. An audit would catch avoidable drift.
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
- Compare shared dependencies (React, Vite, TypeScript, testing libs) across both
package.json files and align versions where there's no reason to differ
Suggested execution
- Fork the repo and create a branch
git checkout -b chore/frontend-dependency-version-audit
- Implement changes
- Update
comebackhere-frontend/package.json and frontend/package.json as needed
- Test and commit
- Run each app's build and test suite after alignment
Example commit message
chore: align shared dependency versions across both frontend apps
Guidelines
- Assignment required before starting
- PR description must include:
Closes #[issue_id]
- Keep PR description professional and detailed
Description
With two separate React frontends and their own
package-lock.jsonfiles, dependency version drift between the two (e.g. different React or Vite major versions) could cause inconsistent behavior or bugs that only reproduce in one app. An audit would catch avoidable drift.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
package.jsonfiles and align versions where there's no reason to differSuggested execution
comebackhere-frontend/package.jsonandfrontend/package.jsonas neededExample commit message
chore: align shared dependency versions across both frontend appsGuidelines
Closes #[issue_id]