Integrate JSHint Static Analysis Tool for JavaScript Code Quality Flagging

[leongcmu]

Resolves #64

Context
NodeBB already lists jshint as a devDependency but it was never configured or wired up for use. This PR completes that integration by adding the necessary configuration files and an npm script so the tool can actually be run by developers on the team. JSHint flags suspicious JavaScript patterns — catching issues like undeclared variables, accidental == instead of ===, and unused variables before they reach production.

Changes in the Codebase
package.json
Added "lint:jshint": "jshint ." to the scripts section
jshint ^2.13.6 was already present in devDependencies — no new package was needed

.jshintrc (new file)
Sets esversion: 6, node: true, browser: true for NodeBB's mixed environment
Enables undef: true, unused: true, eqeqeq: true, and curly: true for stricter code quality checks
Enforces indent: 2 and maxlen: 100

.jshintignore (new file)
Excludes node_modules/, dist/, and coverage/ from analysis

How to Run
bashnpm run lint:jshint
Output:
npm run lint:jshint > jshint-output.txt 2>&1
The existing npm run lint (ESLint) is unchanged.

Evidence of Execution
jshint-output.txt was generated by running npm run lint:jshint and is attached to this PR as proof the tool ran successfully on the repository.
See https://github.com/CMU-313/nodebb-spring-26-team-4/blob/main/jshint-output.txt for full tool output.

Assessment: Pros & Cons

Pros

• Zero-friction install — already a listed devDependency, no new packages needed
• Analyzed all 1,424 JS files quickly — proves it scales to large codebases
• Found 111 real == vs === bugs that could cause type coercion issues
• Found 4,009 unused variables — potential dead code worth reviewing
• Found 88 missing curly braces — small but genuine logic risk
• CI-friendly — exits non-zero on errors, can automatically block failing PRs

Cons

• Poor signal-to-noise ratio out of the box — 37% of all output (17,553 issues) are false positives from configuration gaps, not real bugs
• 11,730 undefined variable false positives — NodeBB's client-side globals (socket, ajaxify, app, config) aren't declared in .jshintrc, so JSHint flags them all as errors
• 5,823 ES version warnings — config is set to esversion: 6 but NodeBB uses async/await and other ES8+ features throughout
• No autofixing — all 17,903 line length violations must be fixed manually, unlike ESLint's --fix
• False positives damage developer trust — when 37% of warnings are wrong, developers learn to ignore all output
• Redundant with ESLint — NodeBB already has a mature ESLint setup

Customization Notes

• A priori (critical): esversion must be bumped to at least 8 to stop async/await warnings; a globals block must be added to .jshintrc declaring NodeBB's client-side globals — without both fixes the output is too noisy to act on
• Over time: maxlen could be relaxed or removed given NodeBB's existing style; maxcomplexity could be added incrementally; inline /* jshint ignore:line */ can handle intentional exceptions

[alexbock2]

Looks good!

[leongcmu]

Project 3B: Tool Analysis and Integration

1. What is the name and high-level description of what the tool does? Provide a link to its documentation/source.
   JSHint is a community-driven static code analysis tool for JavaScript that detects errors and potential problems in JavaScript code. It scans JavaScript files and flags suspicious patterns, style violations, and potential bugs based on configurable rules, helping enforce coding conventions and catch common mistakes before runtime. It's designed to be flexible and customizable to match different coding styles and project requirements.
   Documentation: https://jshint.com/docs/ and https://github.com/jshint/jshint

2. Is the tool used for static or dynamic analysis?
   JSHint performs static analysis. It examines source code without executing it, identifying potential issues by parsing and analyzing the code's structure, patterns, and syntax. No tests or runtime needed.

3. What types of problems does this particular tool catch?
   When run on the NodeBB repo, JSHint catches type coercion bugs (111 instances of == instead of ===), unused variables (4,009 instances of potential dead code), undeclared variables, missing curly braces on control structures (88 instances), line length violations, indentation inconsistencies, and various JavaScript anti-patterns.

4. What types of customization are possible or necessary?
   JSHint is configured via a .jshintrc file. Options include ECMAScript version (esversion), environment globals (node, browser), and enforcement rules like undef, unused, eqeqeq, curly, indent, and maxlen. Files can be excluded via .jshintignore or inline /* jshint ignore:line */ comments.
   For this project specifically, the necessary customizations are bumping esversion to 8+ for async/await support and adding a globals block for NodeBB's client-side globals (socket, ajaxify, app, config, etc.) to eliminate thousands of false positive warnings.

5. How can/should this tool be integrated into a development process?
   JSHint exits with a non-zero status on errors, making it well-suited for CI/CD pipelines that block PR merges on failures. It can also run via pre-commit hooks (e.g., Husky) and has IDE plugins for real-time feedback. Given the 17,000+ existing issues in this codebase, a gradual adoption strategy makes the most sense. This could start by enforcing it on new code only, prioritize fixing critical issues (== vs ===, undeclared variables) first, use inline ignores for known acceptable violations, and incrementally clean up legacy code. Since NodeBB already uses ESLint, we should also decide whether to run both tools in parallel or consolidate rules into ESLint alone.

6. Are there many false positives? False negatives? True positive reports about things you don't care about?
   False positives are a significant problem. When run on the repo, ~37% of the output comes from configuration gaps rather than real bugs. Specifically, 11,730 warnings about undefined variables are false positives caused by NodeBB globals not being declared in .jshintrc, and 5,823 ES version warnings are false because the config is set to esversion: 6 while the codebase uses ES8+ features.
   True positives worth acting on include the 111 ==/=== issues, 4,009 unused variables, and 88 missing curly brace cases.
   True positives we may not care about include the 17,903 line length violations that are technically real rule violations, but have no auto-fix and may not reflect our team’s actual standards which create noise that buries more actionable warnings.
   In regards to false negatives, JSHint won't catch runtime logic errors, async/Promise mistakes, complex type bugs, performance issues, or security vulnerabilities. Configuration issues (ES version and global variables) should be fixed first. When a large portion of warnings are noise, developers stop trusting the tool’s output, which defeats its purpose.