Massachusetts Platform for Legislative Engagement (MAPLE)

A legislative testimony project through Code for Boston!

We are creating a new web platform called MAPLE (the Massachusetts Platform for Legislative Engagement) that makes it easy for residents to submit their testimony to the MA legislature and read the testimony of others. Our goals are to shine a light on the statehouse by 1) providing a public archive of legislative testimony; 2) standardizing and demystifying the testimony process, so that more people can make their voices heard; and 3) creating a space for constituents and legislators to maintain prolonged focus on key issues, and to learn more efficiently about the laws that will shape our lives. Through this, we hope that people can better channel their political energy into productive improvements for our local and state communities.

Essentials

Join the Code for Boston Slack and our #maple-testimony channel. Ask to be added as a collaborator on Github, and provide your Github username.

Attend a weekly hack night at Code for Boston and join our group.

You can find good first issues here.

Check out the Contributing docs for how to contribute to the project, and the wiki for project documentation.

Links

• GitHub issues, where issues are organized
• Figma Designs, where UI designs are organized
• Chromatic Storybook Library, where our React UI component library is documented.
• Maple Documentation on the Wiki
• Docker Desktop Client, for running the full application locally

Live Sites

• Development site, for testing and development. Feel free to play with the site!
• Production site, for public use and real testimony. Please only use this site to submit real testimony, not for testing.

Getting Started

1. Fork a copy of the main repo to your GitHub account.

2. Clone your fork:

git clone https://github.com/YOUR_GITHUB_NAME/maple.git

3. Add the main repo to your remotes:

cd maple
git remote add upstream https://github.com/codeforboston/maple.git
git fetch upstream

Now, whenever new code is merged you can pull in changes to your local repository:

git checkout main
git pull upstream main

4. Now you're ready to work on a feature! See the Contributing page for more info, and refer to the wiki for more documentation.

Developing Locally

1. Make sure that you have node and yarn installed. You can download Node directly here or use a tool like nvm. To install yarn, run npm i -g yarn after installing node.
2. Install dependencies with yarn install.
3. If you are developing backend features involving firebase or typesense, install Docker and Docker Compose V2.
4. Run a command and start developing:

• yarn dev: Start the Next.js development server. Use this if you're working on frontend features. View the app in your browser at localhost:3000. Make some changes to components/ and pages/. The site will automatically update. Your local site will share the same backend as the live development site.
• yarn storybook: Start the Storybook development server. Use this if you're working on UI components. View your storybook at localhost:6006. It will update as you make changes to the stories in stories/.
• yarn dev:up: Run the full application locally using Docker Compose. Use this if you're working on full-stack or backend features in functions/. You can access the emulator UI at http://localhost:3010.
• yarn dev:up:detach: Run the application, and keep it running once you stop this command.
• yarn dev:down: Stop the application.
• yarn dev:update: Update the application images. Run this whenever dependencies in package.json change.

Storybook Firebase Guard

Storybook blocks real Firebase Auth and Firestore calls by default to prevent accidental network access from stories.

If a story triggers a blocked call, Storybook throws an error with guidance about what to mock.

Use these patterns when building stories:

• Prefer passing mock props/data to components instead of rendering hook-driven containers.
• If a component supports injection (for example, mock profile/index props), use that in the story args.
• For auth-driven stories, use the helpers in stories/utils/storybookFirebaseAuth.ts to switch between logged-out and logged-in user mocks.

Opt-out options:

• Per story: set parameters.firebaseGuard.allow = true.
• Globally: run Storybook with STORYBOOK_ALLOW_FIREBASE_CALLS=1.

Install the Redux DevTools and React DevTools browser extensions if you're developing frontend

Contributing Backend Features to Dev/Prod:

• If you are developing backend features involving only Next.js API routes and need to deploy them to the Dev site, you will need to login through Google Cloud Auth:

1. Ensure you are added as an editor of the Firebase project (https://console.firebase.google.com/u/0/project/digital-testimony-dev for development)

2. Download and initialize gcloud : https://cloud.google.com/sdk/docs/install

3. Authenticate with Google Cloud by running: gcloud auth application-default login --no-launch-browser. This will generate an application credentials file using your Google account.

4. At this point, you should also have an environment variable GOOGLE_APPLICATION_CREDENTIALS set to the path to that generated config file. If you have it, your setup is complete. If not, you will need to configure it by:

• Try running the gcloud auth application-default login --no-launch-browser again (for some reason, the environment variable will sometimes not be created on the first login)
• If that doesn't work, you will need to manually set the environment variable. In your .bashrc/.zshrc, add the line: export GOOGLE_APPLICATION_CREDENTIALS=path/to/application_default_credentials.json (with the correct file path)
• The needed file path is documented here, depending on your operating system: https://cloud.google.com/docs/authentication/application-default-credentials#:~:text=User%20credentials%20provided%20by%20using%20the%20gcloud%20CLI,-You%20can%20provide&text=The%20location%20depends%20on%20your,APPDATA%25%5Cgcloud%5Capplication_default_credentials.json
• Once that is set, you should be able to run the dev site from any new command line window/tab.

The main development/production site uses a Google Service Account to authenticate - there is a very low limit on the number of service accounts we can have, so we reserve those for official deployments. The method documented above simulates a service account using your personal Google account as a base to get around this limitation. If needed, the real Service Accounts can be found in the Firebase console: https://console.firebase.google.com/u/0/project/digital-testimony-dev/settings/serviceaccounts/adminsdk)

Testing

MAPLE uses Jest for unit and integration testing, and Playwright for e2e testing.

Environment Setup for Testing.

To set up your environment for testing, make sure you have a .env file configured with the necessary variables. You can create it by copying the provided .env.example template:

cp .env.example .env

This file includes placeholders for key environment variables, which you should customize as needed:

TEST_ADMIN_USERNAME: Username for admin testing.
TEST_ADMIN_PASSWORD: Password for admin testing.
APP_API_URL: The base URL for the application API (default is http://localhost:3000).

Running Tests.

Once your environment is set up, you can start running tests with one of the following commands:

• yarn test:integration [--watch] [-t testNamePattern] [my/feature.test.ts]: Run integration tests in components/ and tests/integration/. These tests run against the full local application -- start it with yarn up. You can use --watch to rerun your tests as you change them and filter by test name and file.
• yarn test:e2e: Run e2e tests in tests/e2e with the Playwright UI
• yarn test:e2e:headless: Run e2e tests in tests/e2e headless (no UI)

For more information on our end-to-end testing, go to our e2e test README. For an introduction on how to write e2e tests with Playwright, go to the Playwright docs. An example of an e2e test can be found in tests/e2e/homepage.spec.ts.

Code Formatting and Linting

We use Prettier and ESLint to check files for consistent formatting and catch common programming errors. When you send out a PR, these run as part of the Repo Checks workflow.

You can install pre-commit so that Prettier and ESLint run automatically when you commit. You can also run yarn fix locally to lint and format your code. You'll need to do one of these and commit the changes if the Linting and Formatting parts of the Code Quality check fails on your PR.

If you use VSCode, consider using our project workspace file (open it in VSCode and click the "Open Workspace" button in the editor). It will ask you to install ESLint and Prettier extensions, which will show lint errors in your editor and set up Prettier as the default code formatter. You can format the current file from the command pallete by typing Format Document. You can also set the editor up to format on save: select Open User Settings from the command pallet, search for format on save, and enable it.

Additional Documentation

See the Wiki

Contributors

Thanks to all our contributors!

This table follows the All Contributors specification and is managed by the @all-contributors bot. You can add yourself or another contributor by commenting on an issue or a pull request.