Integrated Flow static type checker

[Aidanpgh]

Evidence that Flow Tool is installed

Artifacts that demonstrate that it runs in repository correctly

Pros

• Improves code quality and reduces runtime bugs.
• Flow checks files with //https://github.com/flow so you can slowly integrate it into the codebase into specific files.
• It is customizable as the .flowconfig file allows fine grained control over which files and directories are included or ignored through the [include] and [ignore] fields.

Cons

• Flow can be resource-intensive, especially for large codebases, as it needs to analyze and type-check the entire dependency graph. Initial runs may be slow, though performance improves with caching.
• Keeping type definitions up-to-date as the codebase evolves requires ongoing effort and refactoring or introducing new features may require updating multiple type annotations.
• Some third-party libraries may not have Flow type definitions, requiring you to stub or manually define types.

Customization

• Pre-Integration: Configured .flowconfig to include only the src directory and ignore unnecessary files like node_modules and build. Added // https://github.com/flow to specific files to enable type checking incrementally.

• Post-Integration: Stubbing missing type definitions for third-party libraries (e.g., zxcvbn and winston).
  Adding type annotations to existing code incrementally.

[railway-app]

🚅 Deployed to the nodebb-spring-26-clean-cod-pr-65 environment in Clean Code Team (nodebb)

Service	Status	Web	Updated (UTC)
nodebb-spring-26-clean-code	◻️ Removed (View Logs)	Web	Mar 17, 2026 at 1:52 am

[Aidanpgh]

Tool Analysis (Individual) For Part B

What is the name and high-level description of what the tool does? Provide a link to its documentation/source.

My tool is called Flow and it is a static type checker for Javascript. A link to its documentation/source is below:

https://flow.org

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?

Flow checks your code for errors through static type annotations, meaning it analyzes the code without actually running it. It catches type mismatch, null reference errors, incorrect function call signatures, improper use of object properties, improper return statements, spelling mistakes, improper arguments, and other issues that would otherwise only surface as runtime errors or go unnoticed during development.

What types of customization are possible or necessary?

You can edit Flow's config file to control which directories are included or ignorded during analysis. This is important and can be necessary for large projects like NodeBB, where you would like to exclude certain directories. Flow also supports incremental adoption though adding // @flow to the top of individual fiules so that you can enable type checking file-by-file instead of all at once. For third party libraries that lack Flow type definitions, you need to manually write stub type files, which does add some upfront configuration work.

How can/should this tool be integrated into a development process?

Flow is best used as a local development tool that runs alongside your editor as it provides real time feedback as you write code. It can also be integrated into CI as a check on every PR to ensure that any new code introduced to the repository passes type checking before merging. Overall, a practical approach would be to gradually add // @flow to files as they are touched during development rather than trying to annotate the entire codebase at once.

Are there many false positives? False negatives? True positive reports about things you don't care about?

Flow can produce false positives. For example Flow may incorrectly flag valid code as an error with third party libraries that lack Flow type definitions since Flow doesn't know the shape of those types. This can be fixed through writing manual stubs. False negatives are unlikely as Flow analyzes any file that has the // @ flow annotation, meaning any file that is opted in should be fully checked. Therfore, as long as annotations are added consistently, there is littel room for Flow to silently miss errors in the files it is tracking. Flow can produce true positives about things we don't care about because, as mentioned earlier, there is an issue of it incorrectly flagging valid third party code. This could end up generating a fair amount of unanactionable and irrelavent errors, especially when working in large codebases like NodeBB.