Tool: Added flow

[aaronlockhartdev]

Summary

This PR introduces Flow static type checking to the NodeBB codebase, adding an additional layer of type safety to catch potential runtime errors before code is deployed.

Changes Made

CI/CD Pipeline (.github/workflows/test.yaml)

• Added Flow type checking step to the test workflow, running after ESLint and before Node tests

Dependencies (install/package.json)

• Added flow-bin (v0.304.0) for type checking
• Added flow-coverage-report (v0.8.0) for coverage reporting
• Added two new npm scripts:
  • flow: runs flow check for type validation
  • flow-coverage: generates HTML coverage report

Configuration Files

• .gitignore: Added Flow-specific patterns (.flowconfig, .flow*, flow-coverage-report/)
• eslint.config.mjs: Configured ESLint to ignore Flow files and output directories (.flowconfig, flow-coverage-report/)

Benefits

• Catches type-related bugs at development time
• Improves code quality and maintainability
• Integrates seamlessly with existing linting and testing workflows
• Provides coverage reporting for type checking

Testing

The Flow check will run automatically in CI/CD as part of the test pipeline.

P3B Questions

• What is the name and high-level description of what the tool does? Provide a link to its documentation/source.
  Flow is a static type checker for Javascript that enables the use of type annotations to reduce type-related bugs.
• Is the tool used for static or dynamic analysis?
  The tool is used for static analysis.
• What types of problems does this particular tool catch?
  This tool catches type related errors. Javascript is a dynamically and weakly typed language, which can lead to unexpected behavior when unintended type conversions occur. Flow attempts to mitigate these errors by allowing developers to express the intended type for a variable.
• What types of customization are possible or necessary?
  Little customization of the tool itself is possible or necessary; however, it is necessary to choose the tool for stripping flow types (babel or flow-remove-types) in the build process.
• How can/should this tool be integrated into a development process?
  This tool must be integrated into the build process, as type annotations must be stripped prior to building. Flow can be run through npm scripts in a CI/CD pipeline, allowing automatic type checking. Flow must be activated on a file-by-file basis by adding // @flow at the beginning. Developers should use type annotations wherever possible, especially for new code.
• Are there many false positives? False negatives? True positive reports about things you don't care about?
  Flow can result in false positives, as some complex cases can not be adequately represented by type annotations or understood by Flow. False negatives are rare, though the necessity to opt in for each individual file means that some files can be overlooked entirely.