Installed and ran flow (static analysis tool)

[bencondemi]

For this PR, I successfully installed and ran the static analysis tool, Flow, which is a static type checker for javascript.

Below is my concrete evidence that I successfully installed the tool through trackable file changes demonstrating that extra files/NPM packages were installed:

See the txt file included in this commit titled "flow_terminal_output.txt" which serves as my artifact that demonstrates that I successfully ran the tool on the repository. Additionally, see below for a screenshot of the output of the tool:

Answers to questions from writeup:

1. In your evaluations, consider & experiment with the types of customization that are appropriate or necessary for this tool, both a priori (before they can be used in your project) and over time. Assess the strengths and weaknesses of each tool/technique, both quantitatively and qualitatively.

This static analysis tool required some substantial time-investment a priori, as it required me to download and install several dependencies and packages, modify certain files (shown above), and ensure that the proper files were being checked over. The main strength of this tool is that it can alert the programmer to type errors in their JS code while the weakness is that it is not dynamically checking code as the programmer is producing it, therefore, it's possible for errors to go uncatched until the programmer explicitly calls this static tool. Quantitativelty, this tool can help help programmers catch a greater number of bugs/type issues and can reduce the amount of time needed to debug/refactor code. Qualitatively, this tool can help programmers avoid building up technical debt ny repeatedly employing this static analysis tool throughout the development process and can help make the debugging/refactoring process less stressful.

2. What types of problems are you hoping your tooling will catch? What types of problems does this particular tool catch?'
   I am hoping that this tool will catch type errors in my repo. This particular tool catches type errors in JS code.

3. What types of customization are possible or necessary?
   The documentation says the programmer can dictate which files are checked by flow with the // @flow snippet. Additionally, flow can be integrated with other static type checkers/linters such as ESLint.

4. How can/should this tool be integrated into a development process?
   This tool should be integrated into a development process at all stages ranging from initial development to debugging and refactoring. During initial development, this tool should be used to minimize the build up of technical debt and bugs. During the debugging/refactoring process, this tool should be used to debug/refactor with efficiency and confidence.

5. Are there many false positives? False negatives? True positive reports about things you don’t care about?
   Thus far, it is unclear at the exact rates for these metrics; however, it is important that static type checkers minimize their false positives to ensure that programmers will still pay them attention (rather than tuning them out). The Flow documentation does cite that it does fall prey to some false positives due to " [refinement invalidation]"(https://flow.org/en/docs/lang/refinements/#toc-refinement-invalidations).

[bencondemi]

Please notice that the initial PR passed all GitHub actions for the checkpoint. This was prior to DeepScan being integrated and changing the GitHub actions suite that was ran. Thus, this PR passed on all of the original GitHub actions (excluding the additional DeepScan ones) and should be viewed as with a green check.