TypeScript Rules Catalog

Comprehensive catalog of TypeScript code quality rules for Next.js, React.js, React Native, and Nest.js projects

⚡
Next.js
Full-stack React framework
⚛️
React.js
Frontend library
📱
React Native
Mobile development
🚀
Nest.js
Backend framework
97
Total Rules
Across all categories
78%
ESLint Integration
76/97 rules automated
10%
SunLint Heuristic
10/97 rules heuristic
49%
sunlint-vscode
48/97 rules AI-powered
Category Breakdown
Rule distribution across categories and tools
CategoryTotalESLintSunLintVS CodeCoverage
Common Rules33
19
7
13
58%
Security Rules47
43
3
32
91%
TypeScript Rules11
8
0
3
73%
React.js Rules6
6
0
0
100%
ESLint Integration
Automated static analysis
  • Real-time error detection
  • IDE integration
  • CI/CD pipeline support
  • Auto-fix capabilities
SunLint Heuristic
Pattern-based analysis
  • Complex pattern detection
  • Cross-file analysis
  • Architecture validation
  • Custom rule engine
sunlint-vscode
AI-powered semantic analysis
  • GitHub Copilot integration
  • Context-aware analysis
  • Quality score (0-100%)
  • Interactive development
Detailed Rules Catalog
Complete list of TypeScript rules by category
C002
Avoid code duplication > 10 lines
ESLint
VS Code
C003
Use clear variable names; avoid arbitrary abbreviations
ESLint
VS Code
C006
Function names must be verbs or verb-noun combinations
ESLint
SunLint
VS Code
C010
Avoid more than 3 levels of nested blocks
ESLint
SunLint
VS Code
C013
Do not use dead code
ESLint
VS Code
C014
Use Dependency Injection instead of directly instantiating dependencies
ESLint
VS Code
C017
Do not put business logic inside constructors
ESLint
VS Code
C018
Do not throw generic errors; always provide detailed messages
ESLint
VS Code
C019
Do not use `error` log level for non-critical issues
SunLint
C023
Do not declare duplicate variable names in the same scope
ESLint
VS Code
C024
Do not scatter hardcoded constants throughout the logic
C029
All `catch` blocks must log the root cause of the error
ESLint
SunLint
VS Code
C030
Use custom error classes instead of generic system errors
ESLint
VS Code
C031
Validation logic must be separated
SunLint
C033
Separate processing logic and data access in the service layer
C035
Log all relevant context when handling errors
ESLint
VS Code
C040
Do not spread validation logic across multiple classes
C041
Do not hardcode or push sensitive information (token, API key, secret, URL) into the repo
ESLint
SunLint
VS Code
C042
Boolean variable names should start with `is`, `has`, or `should`
ESLint
SunLint
VS Code
C043
Do not use `print` or `console.log` in production code
ESLint
SunLint
VS Code
C047
Retry logic must not be duplicated in multiple places
ESLint
SunLint
VS Code
C048
Do not bypass architectural layers (controller/service/repository)
C052
Parsing or data transformation logic must be separated from controllers
C056
Do not process large datasets without logging or resource monitoring
C060
Do not override superclass methods and ignore critical logic
C061
Write unit tests for business logic
C065
Each test case should verify only one behavior
C067
Do not hardcode configuration inside code
C070
Tests should not rely on real time
C072
Each test should assert only one behavior
ESLint
VS Code
C073
All required configurations must be validated at startup
C075
All functions must explicitly declare return types
ESLint
SunLint
VS Code
C076
All public functions must declare explicit types for arguments
ESLint
SunLint
Development Priorities
Roadmap for enhancing TypeScript support

Phase 1: ESLint Enhancement

  • • Complete remaining 14 Common Rules without ESLint
  • • Develop 4 Security Rules for comprehensive coverage
  • • Add 3 TypeScript Rules for strict type checking

Phase 2: AI Integration

  • • Enhanced VS Code extension capabilities
  • • Context-aware rule suggestions
  • • Automated rule learning from codebase patterns
Get StartedConfigurationView All RulesGitHub Repository

TypeScript Catalog • Version 1.0 • Last Updated: July 2025

Developed by Sun* Engineering Team