[ADR]: Back-end Code Quality Tools

[widal001]

Description

Evaluate and select libraries to enforce the following standards within the backend codebase:

• Dependency management (e.g. conflicts, updates, etc.)
• Code Linting
• Auto-formatting
• Type checking
• Checking for vulnerable dependencies
• Checking for open source licenses
• Unit testing
• Test coverage

Options

Note: The following list of options for these tools assume we are using python, which needs to be decided by #38

• Dependency management
  • pipenv
  • poetry
  • others as recommended
• Code linting
  • ruff
  • flake8
  • pylint
  • others as recommended
• Auto-formatting
  • black
  • autopep8
  • others as recommend
• Type checking
  • mypy
  • pyright
  • pyre
  • others as recommended
• Vulnerable dependencies
  • safety
  • dependency-check
  • others as recommended
• License checking
  • licensecheck
  • pip-licenses
  • others as recommended
• Unit testing
  • unittest
  • pytest
  • others as recommended
• Test coverage
  • coverage.py
  • pytest-cov

Definition of Done

• The ADR is drafted and stored in documentation/[ADR folders TBD]/
• The ADR is included in the necessary table of contents in the ADR/decision folder
• The ADR describes the drivers and pros and cons of the decision
• The ADR has been reviewed and approved by the internal team
• The ADR satisfies requirements that are outlined in the ADR template
• The ADR covers each of the following tools:
  • Dependency management
  • Code linting
  • Auto-formatting
  • Type checking
  • Dependency vulnerability checking
  • License checking
  • Unit tests
  • Test coverage

[daphnegold]

Commit conventions

@acouch and I agree this should be in a separate ADR or working agreement. We already have some great documentation on conventions that might work for us.

[daphnegold]

Branch: <username>/issue-<number>-<brief description>
Commits: Nava Conventions

[widal001]

Commit conventions

@acouch and I agree this should be in a separate ADR or working agreement. We already have some great documentation on conventions that might work for us.

@daphnegold @acouch Good call! I'll create a separate ADR for Git Conventions (e.g. branch naming, merge strategies, commit conventions)

I would love to have this be enforced with some tooling though, for example:

• commitizen (python)
• git-conventional-commits (js)

[daphnegold]

@widal001 as we discussed offline, unit testing and coverage is a big thing on its own. As this ADR keeps growing, that's a clear conceptual place we can split off into another ADR (again :P). Let me know if you'd like me to create that issue or if you're on it!

[acouch]

ref: #50