FAQ & Troubleshooting

ViberTest analyzes JavaScript and TypeScript files: .ts, .tsx, .js, and .jsx. It does not analyze HTML, CSS, Python, or other languages.

ViberTest uses a hybrid approach. Some rules use regex-based content analysis for speed, while others leverage ts-morph (a TypeScript compiler API wrapper) for AST-based analysis when deeper understanding of code structure is needed — for example, detecting circular dependencies, dead code, and code duplication.

No. ViberTest is a project-level health scanner, not a per-file linter. It focuses on architectural patterns, AI-generated code smells, and ship-readiness — things ESLint doesn't check. Use ViberTest alongside your linter, not instead of it.

Node.js >= 20.0.0. ViberTest uses modern Node APIs (ES modules, structured clone, etc.) that require Node 20+.

Yes. Point it at any subdirectory: vibertest scan ./packages/my-app. Each package can have its own .vibertestrc.json. ViberTest searches for config starting from the scan target directory upward.

Common reasons for a low score:

• Critical issues — hardcoded secrets or missing tests have the highest penalty (5 pts each, linear scaling)
• Many high-severity issues — dead code, unused deps, circular dependencies (3 pts each)
• Accumulated medium issues — even with diminishing returns, 20+ medium issues add up

See the Scoring guide for the full formula.

No. Each rule is capped at 15 penalty points maximum. Even if one rule finds 100 issues, it can only deduct 15 points. The exponential decay formula means you need issues across multiple rules to significantly lower your score.

Add it to your config file:

{
  "rules": {
    "pattern-inconsistency": { "enabled": false }
  }
}

Two rules are disabled by default:

• react-performance — intentionally noisy, flags patterns like inline objects in JSX props and array index keys. Enable only when optimizing React rendering.
• missing-tests — recently disabled by default. Many projects have valid reasons for low test coverage early on. Enable it when your team is ready to enforce testing standards.

Disable them. For example, if you're building a Node.js API with no frontend, disable accessibility, react-performance, and missing-production-basics. Some rules like missing-compliance and missing-production-basics are framework-aware and will automatically skip non-web projects.

Yes, use the --rules flag:

$ vibertest scan . --rules hardcoded-secrets,missing-tests,dead-code

These directories are ignored by default. If you're seeing them in results, check if you have a custom ignore array in your config that replaces (not extends) the defaults. The config-level ignore replaces the default list, but ViberTest always applies its built-in ignore patterns (node_modules, dist, build, .next, etc.) at the file collection level regardless of your config.

ViberTest uses fast-glob for file collection and a hybrid approach (ts-morph + regex) for analysis, so it's generally fast. If it's slow:

• Make sure you're not scanning a directory with many non-JS files
• Add large generated directories to your ignore list
• Use --rules to run only the rules you care about
• The circular-deps rule does DFS graph traversal and can be slow on very large codebases

The dead-code rule checks if named exports are imported anywhere in the project. It may flag exports that are used externally (by other packages, or consumed via dynamic imports). Entry point files (index, main, app, layout, page, route), test files, barrel re-exports, .d.ts files, and Storybook stories are automatically excluded.

Exit code 2 means the scan itself failed. Common causes:

• Malformed config file (invalid JSON/YAML)
• Permission errors reading files
• Internal error during rule execution