- Created .gitignore to exclude sensitive files and directories. - Added API documentation in API_DOCUMENTATION.md. - Included deployment instructions in DEPLOYMENT.md. - Established project structure documentation in PROJECT_STRUCTURE.md. - Updated README.md with project status and team information. - Added recommendations and status tracking documents. - Introduced testing guidelines in TESTING.md. - Set up CI workflow in .github/workflows/ci.yml. - Created Dockerfile for backend and frontend setups. - Added various service and utility files for backend functionality. - Implemented frontend components and pages for user interface. - Included mobile app structure and services. - Established scripts for deployment across multiple chains.
3.1 KiB
3.1 KiB
Submodule Setup Guide
Current Structure (Option 3)
This repository follows Option 3 structure:
- Backend (
backend/): Monorepo containing API, middleware, jobs, services, and GraphQL - all tightly coupled components - Contracts (
contracts/): Currently a regular directory, ready to be converted to a submodule - Frontend (
frontend/): Currently a regular directory, ready to be converted to a submodule
Why This Structure?
Backend as Monorepo
The backend components (API routes, middleware, jobs, services) are kept together because:
- They share the same
package.jsonand dependencies - They use the same database schema (Prisma)
- They deploy as a single service
- They have tight coupling and shared business logic
- No independent versioning needed
Contracts & Frontend as Submodules (When Ready)
These components can be submodules because:
- They have independent tooling (Foundry vs Next.js)
- They can have separate release cycles
- They may be developed by different teams
- They can be reused in other projects
Converting to Submodules
Option A: Automated Setup (Recommended)
Use the provided script with a GitHub token to automatically create repositories and set up submodules:
# Set your GitHub token (create one at https://github.com/settings/tokens)
export GITHUB_TOKEN=your_github_token_here
# Run the setup script (optionally specify org/username)
./scripts/setup-submodules.sh [your-github-org-or-username]
The script will:
- ✅ Create GitHub repositories for contracts and frontend
- ✅ Push the code to those repositories
- ✅ Convert them to git submodules
- ✅ Commit the submodule configuration
Required GitHub Token Permissions:
reposcope (to create repositories and push code)
Option B: Manual Setup
When you're ready to convert contracts/ and frontend/ to proper git submodules, follow these steps:
Prerequisites
- Create remote repositories for
contractsandfrontend(e.g., on GitHub, GitLab, etc.) - Push the existing code to those remotes
Steps
-
Remove current directories from main repo:
git rm -r contracts frontend git commit -m "Remove contracts and frontend before submodule conversion" -
Add as submodules:
git submodule add <contracts-remote-url> contracts git submodule add <frontend-remote-url> frontend -
Commit the submodule configuration:
git add .gitmodules contracts frontend git commit -m "Add contracts and frontend as submodules"
Working with Submodules
Cloning the repository:
git clone --recurse-submodules <repo-url>
# Or if already cloned:
git submodule update --init --recursive
Updating submodules:
git submodule update --remote
Making changes in submodules:
cd contracts
# Make changes, commit, push
cd ..
git add contracts
git commit -m "Update contracts submodule"
Current Status
- ✅ Backend is a unified monorepo (API, middleware, jobs together)
- ✅ Contracts and frontend are regular directories (no nested .git)
- ⏳ Ready to convert to submodules when remotes are created