[Task]: Front-end Repo Setup

[widal001]

Summary

Set up the front-end portion of the repository with the language decided in #96 and the set of code quality tools selected in #102

User Stories

• As an open source contributor, I want to:
  • be able to reference documentation explaining how to use the developer tools, so that I don't have to learn how to use these tools on my own in order to contribute to the project
  • have full test coverage for the codebase, so that I know when I've introduce code that changes or breaks existing behavior
  • have code formatting and standards enforced with automated tooling, so that I don't have to learn and check that my code adheres to those standards manually
• As a maintainer of the project, I want to:
  • have code quality checks run automatically on each push, so that formatting, linting, or security issues are caught before being deployed to production
  • ensure that new contributions meet certain thresholds for test coverage, so that code contributions from internal and external developers also include tests which validate the code's behavior

Acceptance Criteria

• A frontend/ sub-directory has been created with a README that includes instructions for how to install and run the code in this sub-directory
• At least 2 dependencies have been added to the project, and the dependency manager selected in [ADR]: Front-end Code Quality Tools #102 automatically checks for dependency conflicts and offers suggestions for how to reconcile those conflicts:
• A dummy test has been created (i.e. assert True) that users can execute to verify they've installed the project correctly
• The following checks are run before every commit:
  • Auto-formatting
  • Linting (basic)
  • Type checks (optional)
  • [ ] Commit formatting (preferably conventional commit)
• The following checks are run with each push to the remote GitHub repo, and these checks are run against all minor versions of the backend language we plan to support:
  • Auto-formatting
  • Linting (complete)
  • Type checks
  • Dependency vulnerability checks
  • Open source license checks
  • Unit tests
  • Test coverage
• A PR is blocked from merging if any of the checks above fail
• At least 2 people who did not contribute to this PR have installed and run the dummy test locally

Proposed Testing Strategy

1. Unit tests: Create a test_sample test that simply asserts true or asserts the version number
2. Manual Tests: Someone who did not contribute to the PR checks out the PR locally, follows the instructions in the README to install the code, run the tests and the code quality checks locally, and all checks/tests pass.

[acouch]

We have the opportunity to utitlize a NextJS template focused on federal level clients. Some of the features and benefits of this template is:

• This is a Next.js React web application, written in TypeScript.
• U.S. Web Design System provides themeable styling and a set of common components.
• React-USWDS provides React components already with USWDS theming out of the box. For a reference point starting out, see react-uswds-hello.tsx which includes examples of react-uswds component usage.
• Storybook is included as a frontend workshop.

[SammySteiner]

Moving commit formatting and license check to other tickets:
#223
#292

Noting that when we add infrastructure setup via terraform, we'll include a github workflow that uses the grype file for dependency vulnerability checking in the ci/cd pipeline.