mount-vernon-trail

Intro

Hello and welcome to the Friends of the Mount Vernon Trail project! We'll be working, communicating, and logging bugs here, as well as in our other communication channels.

Volunteers use the app to document trail issues during a work event: they photograph a problem before and after fixing it, record metrics, and publish a summary to Trello. The photos go into a shared Google Photos album owned by the MVT account, which is what the backend exists to make possible.

Repo layout

• frontend/ — the Expo (React Native) app. cd frontend && npm install && npm start.
• backend/ — Node + TypeScript service that proxies Google Photos uploads into the MVT-owned album. Volunteers authenticate to it with their Firebase ID token; it holds the single Google refresh token. Deployed on Render. See backend/README.md for the API and setup.
• firestore.rules / firestore.indexes.json — Firestore security rules and composite indexes. Deployed by a lead, indexes before rules — see Admin setup.
• firestore/ — emulator-backed tests for those rules.

Setup

For every engineer. Ask a lead for the .env values; the app and backend both run against the shared friends-of-mvt Firebase project.

1. cd frontend && npm install, then cp .env.example .env and fill it in.
2. cd backend && npm install, then cp .env.example .env and fill it in.

That is all a development machine needs. Don't run the admin steps below against the shared project unless you are the one doing them for the team.

Admin setup (once per Firebase project, leads only)

These change shared state for everyone, so they are done once per project, not per engineer:

• If the project has data from before the ownership refactor (true of friends-of-mvt until the refactor is deployed), follow the ownership migration runbook instead of the deploy step below. It deploys indexes and rules itself, with a backfill in between; deploying rules first locks users out of their events.

• Deploy Firestore indexes, then rules, in that order, from the repo root. Wait for every index to report READY before deploying rules; --pretty is what makes the output show each index's state.

  npx firebase deploy --only firestore:indexes
  npx firebase firestore:indexes --pretty
  npx firebase deploy --only firestore:rules

• Grant the admin claim to the people who need it: cd backend && npm run set-admin -- someone@example.com. They sign out and back in for it to take effect.

• Link the MVT Google account to the backend — see the backend README.

Checks

Both halves run the same three gates; CI enforces them on every PR.

cd frontend  && npm run typecheck && npm run lint && npm test
cd backend   && npm run typecheck && npm run lint && npm test
cd firestore && npm test   # boots the Firestore emulator, asserts firestore.rules

The rules suite needs Java (for the emulator) but no credentials and no live Firebase project — it runs firestore.rules against a throwaway emulator instance. firebase-tools is a local devDependency of firestore/, so use npx firebase rather than a global install.

MANUAL_TEST_PLAN.md covers the flows that need real Google/Trello credentials.

Procedures

Cloning

Please clone with SSH. See here to set up a key for your device if it doesn't have one already. Check this out for step-by-step instructions on cloning a repo.

Making branches, commits, + PRs

Explore the PR documentation

Every task will be completed on its own branch. If there are multiple engineers on your task, you can all use the same branch. You can create the remote branch first or create locally and push it.

Branch naming convention: Please start new feature task branches with feature/ and bug fix task branches with bugfix/.

Aim for short, descriptive commit messages. A good way to think about it is to imagine your commit message finishes the sentence "This commit will...". Also, double-check that you're on your branch and not committing secrets or .env information. Then, push your changes to your branch!

Pull from main, merge it into your branch, and test your code again before PRing. This will hopefully mean that you'll be all set to merge once we approve it.

When you're done with the task and have tested your code, make a PR for us to review. Give it a descriptive title. A template should populate with guidelines on how to fill out the description. The more information you give us, the faster we'll be able to get your PR approved!

Requesting review: Our github usernames are bsthapar and asea-aranion.

An example

git checkout -b feature/login

# add/edit files

# the following can also be done in vscode source control
git add -A
git commit -m "create login page frontend"
git push -u origin feature/login
# for subsequent pushes, just 'git push' will work

# repeat until task is complete

git checkout main
git pull origin main
git checkout feature/login
git merge main
# resolve conflicts
# open github and make PR

Meet the engineers!

Fall 2026

Nathan James	John Vu	Name
Name	Name	Soumya Jaiswal
Name	Name	Name

Spring 2026

Name	James Zhou	Jai Patel
Aaryan Patel	Ryan Zhao	Name
Chloe Thompson	Srinidhi Gubba	Indira Shafii