@dmitryrechkin/eslint-standard 1.4.2 → 1.4.3

package/README.md

@@ -1,800 +1,200 @@
-
 # @dmitryrechkin/eslint-standard
 
-A comprehensive ESLint configuration package with TypeScript support, featuring **automatic formatting and code organization**. This configuration enforces consistent code style across projects with powerful auto-fixing capabilities for imports, class members, JSDoc comments, and more.
-
-## ✨ Features
-
-### **Auto-Fixing Capabilities**
-- 🔄 **Automatic Import Sorting**: Organizes imports with type imports and regular imports properly grouped
-- 🏗️ **Class Member Ordering**: Auto-reorders class members by visibility (public → protected → private) and type (fields → constructor → methods)
-- 📝 **JSDoc Alignment**: Automatically fixes JSDoc comment indentation and alignment with proper tab formatting
-- 📑 **JSDoc Requirements**: Enforces comprehensive JSDoc documentation with auto-generation of comment blocks
-- 🧹 **Unused Import Removal**: Automatically detects and removes unused imports
-
-### **Code Style Enforcement**
-- **TypeScript Support**: Full integration with `@typescript-eslint` for TypeScript-specific best practices
-- **Modern JavaScript**: Supports ECMAScript 2020 and newer features
-- **Consistent Formatting**: Enforces Allman brace style, tab indentation, single quotes, and semicolons
-- **Naming Conventions**: Comprehensive naming rules for variables, functions, classes, and more
-- **JSDoc Documentation**: Requires comprehensive documentation for all exported functions, classes, methods, interfaces, types, and enums
-- **Code Complexity Rules**: Industry-standard complexity metrics to ensure maintainable code
-- **Customizable**: Flexible configuration options for different project needs
-
-## 📦 Installation
-
-### Install the Package and Peer Dependencies
-
-```bash
-npm install @dmitryrechkin/eslint-standard --save-dev
-```
+A comprehensive ESLint configuration package with TypeScript support, featuring Prettier integration and industry-standard rules.
 
-### Install Required Peer Dependencies
+## 🚀 Quick Start
 
-```bash
-npm install eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin eslint-plugin-unused-imports @stylistic/eslint-plugin eslint-plugin-jsdoc eslint-plugin-simple-import-sort eslint-plugin-perfectionist --save-dev
-```
+### Installation
 
-Or using a single command:
 ```bash
-npm install @dmitryrechkin/eslint-standard eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin eslint-plugin-unused-imports @stylistic/eslint-plugin eslint-plugin-jsdoc eslint-plugin-simple-import-sort eslint-plugin-perfectionist --save-dev
+npm install -D @dmitryrechkin/eslint-standard
+npx @dmitryrechkin/eslint-standard install-deps
 ```
 
-## 🚀 Usage
-
-### ESLint 9+ Flat Config (Recommended)
-
-Create an `eslint.config.mjs` file in your project root:
+### Basic Usage
 
 ```javascript
-import eslintStandard from '@dmitryrechkin/eslint-standard';
+// eslint.config.mjs
+import config from '@dmitryrechkin/eslint-standard';
 
-export default eslintStandard({
-  tsconfigPath: './tsconfig.json', // Optional: specify path to your tsconfig
-  files: ['**/*.{js,jsx,ts,tsx}'], // Optional: specify file patterns
-  ignores: ['dist/**', 'node_modules/**'] // Optional: additional ignore patterns
+export default config({
+	tsconfigPath: './tsconfig.json'
 });
 ```
 
-### Advanced Configuration
-
-```javascript
-import eslintStandard from '@dmitryrechkin/eslint-standard';
-
-export default eslintStandard({
-  tsconfigPath: './tsconfig.json',
-  files: ['src/**/*.{ts,tsx}', 'tests/**/*.{ts,tsx}'],
-  ignores: ['dist/**', 'coverage/**'],
-  plugins: {
-    // Add custom plugins
-  },
-  rules: {
-    // Override or add custom rules
-    'no-console': 'warn',
-    'perfectionist/sort-classes': 'off', // Disable auto class member sorting if needed
-    // Disable JSDoc requirements if needed
-    'jsdoc/require-jsdoc': 'off',
-    'jsdoc/require-description': 'off',
-    // Disable type hint requirements (if you prefer TypeScript-only types)
-    'jsdoc/require-param-type': 'off',
-    'jsdoc/require-returns-type': 'off',
-    'jsdoc/no-types': ['error', { contexts: ['any'] }]
-  }
-});
-```
+## 📋 Available Presets
 
-### Multiple Configurations
+### Standard (Default)
+Balanced configuration suitable for most projects.
 
 ```javascript
-import eslintStandard from '@dmitryrechkin/eslint-standard';
-
-export default [
-  // Configuration for source files
-  eslintStandard({
-    tsconfigPath: './tsconfig.json',
-    files: ['src/**/*.{ts,tsx}']
-  }),
-  
-  // Configuration for test files with different rules
-  eslintStandard({
-    tsconfigPath: './tsconfig.json',
-    files: ['tests/**/*.{ts,tsx}'],
-    rules: {
-      'no-console': 'off' // Allow console in tests
-    }
-  })
-];
-```
-
-## 🛠️ Package.json Scripts
-
-Add these scripts to your `package.json` for easy linting and formatting:
-
-```json
-{
-  "scripts": {
-    "lint": "eslint .",
-    "lint:fix": "eslint . --fix",
-    "format": "eslint . --fix"
-  }
-}
+import config from '@dmitryrechkin/eslint-standard';
+export default config();
 ```
 
-### Usage Examples
-
-```bash
-# Check for linting errors
-npm run lint
-
-# Auto-fix all fixable issues (imports, member ordering, JSDoc alignment, etc.)
-npm run lint:fix
+### Aggressive
+Enhanced unused code detection for maximum code quality.
 
-# Same as lint:fix
-npm run format
-```
-
-## 🎯 What Gets Auto-Fixed
-
-When you run `eslint --fix`, this configuration will automatically:
-
-1. **📤 Sort Imports**: Organize import statements with type imports grouped correctly
-2. **🔄 Reorder Class Members**: Arrange class members by visibility and type:
-   - Static properties → Instance properties → Constructor → Static methods → Instance methods
-   - Within each group: public → protected → private
-3. **📝 Fix JSDoc Comments**: 
-   - Generate missing JSDoc comment blocks for functions, classes, methods, interfaces, types, and enums
-   - Align JSDoc comments with proper tab indentation
-   - Add parameter and return value placeholders
-4. **🧹 Remove Unused Imports**: Clean up unused import statements
-5. **✨ Format Code**: Apply consistent spacing, quotes, semicolons, and brace styles
-
-## 📊 Code Complexity Rules
-
-This configuration includes industry-standard complexity rules to ensure code maintainability:
-
-### Why Complexity Matters
-Research shows that code complexity directly correlates with:
-- **Bug Density**: Complex code has 2-3x more bugs (McCabe, 1976)
-- **Maintenance Cost**: 80% of software cost is maintenance (Boehm, 1987)
-- **Developer Productivity**: Simple code is understood 5x faster (Shepperd, 1988)
-- **Testing Difficulty**: Complex functions require exponentially more test cases
-
-### Industry Standards & Research
-Our pragmatic thresholds balance ideal practices with real-world needs:
-- **McCabe Cyclomatic Complexity**: <10 is ideal, 15 is acceptable (NIST 500-235)
-- **Function Length**: 50-100 lines is reasonable for complex business logic
-- **Code Complete** (Steve McConnell): Maximum nesting depth of 3-4 levels
-- **Linux Kernel Style Guide**: 3 levels of indentation maximum
-- **Google Style Guide**: Functions that fit on one screen (roughly 50-80 lines)
-- **Real-world experience**: Most well-maintained codebases have functions under 50 lines
-
-### Built-in Complexity Metrics
-All complexity rules use ESLint's built-in rules - no additional packages needed:
-- **Cyclomatic Complexity**: Max 10 paths through a function (pragmatic balance)
-- **Function Length**: Max 100 lines per function (realistic for complex logic)
-- **Statement Count**: Max 20 statements per function
-- **Nesting Depth**: Max 3 levels of block nesting
-- **Callback Nesting**: Max 3 levels of nested callbacks
-- **Parameters**: Max 4 parameters per function
-- **File Length**: Warning at >300 lines per file
-- **Line Length**: Max 120 characters (ignoring URLs and strings)
-- **Early Returns**: Enforces guard clauses and early returns
-- **No Nested Ternary**: Prevents complex conditional expressions
-
-### Customizing Complexity Thresholds
 ```javascript
-export default eslintStandard({
-  tsconfigPath: './tsconfig.json',
-  rules: {
-    // Adjust complexity limits for legacy code
-    'complexity': ['error', 15], // Allow up to 15
-    'max-lines-per-function': ['error', { max: 100 }], // Allow longer functions
-    'max-depth': ['warn', { max: 4 }], // Warn instead of error
-    // Or disable specific rules
-    'max-lines': 'off' // Disable file length check
-  }
-});
+import config from '@dmitryrechkin/eslint-standard/aggressive';
+export default config();
 ```
 
-## 🛡️ Additional Bulletproof Code Rules
-
-### Currently Enforced
-Beyond complexity, this configuration enforces comprehensive bulletproof code rules using ESLint core and TypeScript ESLint plugin (no additional packages needed):
-
-**Type & Promise Safety**
-- Explicit function return types required
-- **No `any` type allowed** - use `unknown` or specific types
-- No floating promises - must await or handle
-- Only await actual promises (no awaiting non-thenables)
-- No unnecessary `return await`
-- Async functions must contain `await`
-- No async in Promise constructor
-
-**Array & Collection Safety**
-- No `delete` on arrays (use splice)
-- Array methods must return values in callbacks
-- No duplicate imports
-- Unique enum values
-
-**Error Handling & Control Flow**
-- Only throw Error objects (no string literals)
-- No empty catch blocks
-- No switch case fallthrough without comment
-- No unreachable code after return/throw
-
-**Null/Undefined Safety**
-- Warns on always-truthy/falsy conditions
-- Safe optional chaining usage
-- No variable shadowing
-- Define variables before use
-
-**Loop & Performance Safety**
-- Correct loop direction (prevents infinite loops)
-- Loop conditions must be modifiable
-- Warns on `await` in loops (performance)
-
-**Security Basics**
-- No `eval()` or implied eval
-- No `new Function()`
-- No string-based setTimeout/setInterval
-
-**Code Clarity & Immutability**
-- Always use curly braces (prevents bugs)
-- Strict equality (`===` and `!==`) required
-- `const` for unchanged variables, no `var`
-- **Magic numbers warning** - Common values allowed (0, 1, -1, 2, 10, 100, 1000, HTTP codes, time constants)
-- **No parameter reassignment** - Can't reassign parameters, but property mutation allowed for practical reasons
-- Console.log warnings (only warn/error allowed)
-- No side-effect free expressions (short-circuit `&&`/`||` allowed)
-- Early returns encouraged
-
-### What's NOT Included (Too Strict for Most)
-These rules are powerful but may be too strict for some teams:
+**Features:**
+- ✅ Enhanced unused variable detection
+- ✅ Import/export cleanup  
+- ✅ Dead code detection (unreachable code)
+- ✅ Strict unused expressions rules
+- ✅ TypeScript-specific cleanup
+
+### Library
+Optimized for TypeScript libraries with strict API requirements.
 
 ```javascript
-export default eslintStandard({
-  tsconfigPath: './tsconfig.json',
-  rules: {
-    // Ultra-strict type safety
-    '@typescript-eslint/strict-boolean-expressions': 'error', // No truthy/falsy
-    '@typescript-eslint/no-non-null-assertion': 'error', // No ! operator
-    
-    // Extreme conventions
-    'no-implicit-coercion': 'error', // Explicit type conversions
-    'id-length': ['error', { min: 2 }], // Minimum variable name length
-    
-    // Pure functional programming
-    'no-let': 'error', // Only const allowed
-    '@typescript-eslint/prefer-readonly-parameter-types': 'error', // Deep immutability
-  }
-});
+import config from '@dmitryrechkin/eslint-standard/library';
+export default config();
 ```
 
-### Pragmatic Adjustments
+**Features:**
+- ✅ Very strict unused exports detection
+- ✅ API documentation requirements (JSDoc)
+- ✅ Explicit return types
+- ✅ No console/debugging code
+- ✅ Enhanced type safety rules
 
-Our rules balance strictness with real-world practicality:
+## ⚙️ Configuration Options
 
-1. **Magic Numbers**: Set to `warn` instead of `error`, with common values pre-allowed
-2. **Parameter Mutation**: Properties can be mutated (common in normalization functions)
-3. **Short-Circuit Evaluation**: `condition && doSomething()` pattern is allowed
-4. **Console Warnings**: Only warns to allow debugging
-5. **Await in Loops**: Warning only - sometimes sequential is intentional
+All configurations accept the same configuration options:
 
-### Handling `any` Types
-While `any` is banned by default, you can:
-1. Use `unknown` for truly unknown types
-2. Use proper type assertions
-3. Temporarily disable for migration:
 ```javascript
-// eslint-disable-next-line @typescript-eslint/no-explicit-any
-const legacyData: any = oldApi.getData();
+export default config({
+	tsconfigPath: './tsconfig.json',    // Path to TypeScript config
+	ignores: ['build/**', 'dist/**'],   // Additional ignore patterns
+	files: ['src/**/*'],                // File patterns to lint
+	rules: {                           // Rule overrides
+		'no-console': 'warn'
+	}
+});
 ```
 
-## 📊 Industry Standards Comparison
-
-### How We Compare to Popular Configurations
-
-This configuration is **more comprehensive and stricter** than industry standards while maintaining practical flexibility:
+## 🛠️ CLI Commands
 
-| Configuration | Immutability | Complexity | Security | TypeScript | Assessment |
-|---------------|-------------|------------|----------|------------|------------|
-| **Airbnb** | Basic (`prefer-const`, `no-param-reassign`) | None | Basic | Limited | ✅ Most popular |
-| **Google** | Basic (`prefer-const`) | None | Basic | Limited | ✅ Clean & simple |
-| **Standard** | Basic (`prefer-const`) | None | Basic | Limited | ✅ Zero config |
-| **This Config** | **Pragmatic immutability guidance** | **10+ complexity metrics** | **12+ security rules** | **25+ TS-specific rules** | 🟢 **Enterprise-grade** |
+The package includes a CLI for dependency management:
 
-### **🎯 Where We Excel Beyond Standards:**
-
-#### **Functional Programming & Immutability**
-- **Airbnb/Standard**: Only basic `prefer-const` and `no-param-reassign`
-- **This Config**: Pragmatic immutability guidance (`prefer-const`, `prefer-readonly-type`, `no-param-reassign`)
-- **Advantage**: Encourages immutability without dogmatic restrictions that break real-world patterns
-
-#### **Code Complexity Management**
-- **Industry Standard**: Usually no complexity rules (default: 20 cyclomatic complexity)
-- **This Config**: Comprehensive complexity metrics (cyclomatic: 10, cognitive: 15, max-lines: 100)
-- **Advantage**: Catches maintainability issues before they become technical debt
-
-#### **Security & Safety**
-- **Industry Standard**: Basic or no security rules
-- **This Config**: 12+ security rules + 25+ TypeScript safety rules
-- **Advantage**: Enterprise-level security scanning built-in
-
-#### **TypeScript Integration**
-- **Industry Standard**: Basic TypeScript support
-- **This Config**: Comprehensive TypeScript-specific safety and style rules
-- **Advantage**: Leverages TypeScript's full potential for bug prevention
-
-### **🔍 Practical Impact vs Industry Standards**
-
-| Metric | Airbnb/Standard | This Configuration | Improvement |
-|--------|-----------------|-------------------|-------------|
-| **Bug Prevention** | ~60-70% | **~95%** | **+35% fewer bugs** |
-| **Security Coverage** | ~20% | **~90%** | **+70% security coverage** |
-| **Maintainability** | No metrics | **Comprehensive** | **Prevents technical debt** |
-| **Type Safety** | Basic | **Advanced** | **Prevents runtime errors** |
+```bash
+# Install all peer dependencies
+npx @dmitryrechkin/eslint-standard install-deps
 
-### **⚖️ Industry Position**
+# Check if dependencies are installed
+npx @dmitryrechkin/eslint-standard check-deps
 
+# Auto-install missing dependencies
+npx @dmitryrechkin/eslint-standard check-deps --install
 ```
-Basic     Standard    Airbnb    This Config    Ultra-Strict
-├─────────├───────────├─────────├──────────────├─────────────┤
-└─ Google          └─ Most      └─ You're here   └─ Impractical
-   Standard           teams                        (dogmatic)
-```
-
-**Verdict**: This configuration provides **enterprise-grade code quality** while remaining **practically usable** - significantly more comprehensive than industry standards.
-
-## ⚠️ Warning vs Error Philosophy
-
-### **The Problem with Warnings Nobody Fixes**
-
-> *"If we can pass then should not even display anything because nobody is going to get back to fix it"*
-
-This configuration takes a **practical approach** to warning vs error severity:
-
-### **🔴 Rules Set to ERROR (Build Breaking)**
-These **must be fixed** before deployment - they represent serious bugs or security issues:
-
-**Type & Promise Safety**
-- `@typescript-eslint/no-explicit-any` - No `any` types (use `unknown`)
-- `@typescript-eslint/no-floating-promises` - Must await or handle promises
-- `@typescript-eslint/no-misused-promises` - Correct promise usage
-- `@typescript-eslint/only-throw-error` - Only throw Error objects
-
-**Security & Safety**
-- `no-eval`, `no-implied-eval` - No eval usage
-- `security/detect-pseudoRandomBytes` - Cryptographically secure random
-- `security/detect-unsafe-regex` - Prevent ReDoS attacks
-- `no-secrets/no-secrets` - Block secrets in code
 
-**Code Quality**
-- `complexity: 10` - Hard limit on function complexity
-- `max-params: 4` - Maximum 4 parameters per function
-- `sonarjs/cognitive-complexity: 15` - Cognitive complexity limit
+## 🎯 Rule Categories
 
-### **⚠️ Rules Set to WARN (Guidance Only)**
-These provide **guidance** but don't break builds - developers **should** address them but **can** proceed:
+### Code Quality & Safety
+- **Type Safety**: Strict TypeScript rules, ban `any` type
+- **Error Prevention**: Catch common bugs and unsafe patterns
+- **Security**: Prevent common security vulnerabilities
+- **Performance**: Avoid performance anti-patterns
 
-**Code Improvement**
-- `no-magic-numbers` - Named constants preferred (but exceptions allowed)
-- `id-length` - Descriptive names encouraged
-- `@typescript-eslint/naming-convention` - Consistent naming
+### Code Style & Formatting
+- **Brace Style**: Allman style (braces on new lines) via Prettier
+- **Indentation**: Tabs with consistent spacing
+- **Import Organization**: Automatic import sorting and grouping
+- **JSDoc**: Required documentation with proper formatting
 
-**Performance Hints**
-- `no-await-in-loop` - Usually better alternatives exist
-- `promise/prefer-await-to-then` - Modern async/await preferred
-- `unicorn/no-array-reduce` - Often clearer alternatives exist
+### Modern JavaScript/TypeScript
+- **ES2020+ Features**: Prefer modern syntax and APIs
+- **Functional Programming**: Pragmatic immutability patterns
+- **Promise Handling**: Proper async/await usage
+- **Import/Export**: Clean module system usage
 
-**File Organization**
-- `max-lines: 300` - Suggests file splitting
-- `import/max-dependencies: 20` - Suggests decoupling
+## 📊 Preset Comparison
 
-**Test-Specific Flexibility**
-- Test files have relaxed warnings since test code has different requirements
+| Feature | Standard | Aggressive | Library |
+|---------|----------|------------|---------|
+| Unused imports cleanup | ✅ | ✅ | ✅ |
+| Unused variables detection | Basic | Enhanced | Enhanced |
+| Dead code detection | Basic | ✅ | ✅ |
+| Unused exports check | ❌ | ✅ | Very Strict |
+| JSDoc requirements | Basic | Basic | Strict |
+| Console statements | Warning | Warning | Error |
+| Return type hints | Error | Error | Explicit |
+| Type safety | High | High | Very High |
 
-### **🎯 Conversion Strategy**
+## 🔧 External Tools Integration
 
-**Practical Functional Programming Rules Applied:**
-- `functional/no-let` → **DISABLED** (replaced with smarter `prefer-const` rule)
-- `functional/prefer-readonly-type` → Keep as `warn` (immutability guidance for interfaces)
-- `functional/immutable-data` → **DISABLED** (incompatible with common JS/TS patterns)
-
-**Reasoning**: 
-
-**🚫 Why `functional/immutable-data` is Disabled:**
-This rule is fundamentally incompatible with common, legitimate JavaScript/TypeScript patterns:
-
-```typescript
-// ❌ Rule would complain about these common patterns:
-const result = {};
-result.user = await findUser();        // Builder pattern
-result.customer = await findCustomer(); // Gradual construction
-
-const config = {};
-config.apiUrl = process.env.API_URL;   // Configuration building
-config.timeout = 5000;                // Property assignment
-
-const data = [];
-data.push(item);                      // Array building
-```
-
-**🔄 Why `functional/no-let` is Replaced:**
-
-The `functional/no-let` rule produces **misleading warnings** because it can't understand control flow:
-
-```typescript
-// ❌ functional/no-let incorrectly warns about these:
-let events = [];           // But gets reassigned in try-catch!
-let claimId = undefined;   // But gets reassigned conditionally!
-
-// ✅ Built-in prefer-const is much smarter:
-let count = 0;    // No warning - gets incremented  
-const name = 'x'; // Would warn if you used 'let' here
-```
-
-**Alternative**: Use ESLint's built-in `prefer-const` rule - it's **smarter** and produces **fewer false positives**.
-
-### **🏗️ Build vs Development Experience**
+For comprehensive unused code detection, consider these additional tools:
 
 ```bash
-# ✅ BUILD PASSES - Critical issues only
-npm run lint
-
-# ⚠️ SHOWS WARNINGS - Full guidance
-npm run lint:dev  # (if you want to see all warnings)
-```
-
-**Result**: Builds only fail for **serious issues** that **must** be fixed, while warnings provide **improvement guidance** without blocking development.
+# Find unused exports
+npx ts-prune
 
-## 🔄 Pragmatic Approach to Functional Programming
+# Find unused files  
+npx unimported
 
-### **Philosophy: Flexibility Over Dogma**
+# Advanced dead code analysis
+npx knip
 
-This configuration takes a **pragmatic approach** to functional programming rules, allowing developers to choose the right tool for each situation rather than enforcing rigid patterns that often conflict with real-world JavaScript/TypeScript development.
-
-### **🎯 Key Rule Decisions**
-
-#### **Loop Statements: Choose What's Best**
-- `functional/no-loop-statements`: **OFF** - Use `forEach`, `for...of`, or traditional loops based on what's clearest
-- `unicorn/no-array-for-each`: **OFF** - Prevents automatic conversion that fights with your choices
-
-**Why**: Different situations call for different approaches:
-```typescript
-// ✅ forEach for side effects with clean syntax
-items.forEach(item => console.log(item));
-
-// ✅ for...of when you need break/continue
-for (const item of items) {
-    if (shouldSkip(item)) continue;
-    if (shouldStop(item)) break;
-    process(item);
-}
-
-// ✅ Traditional for loop when you need the index
-for (let i = 0; i < items.length; i++) {
-    items[i] = transform(items[i], i);
-}
-```
-
-#### **Readonly Types: Practical Over Pure**
-- `functional/prefer-readonly-type`: **OFF** - Too aggressive, adds `readonly` everywhere breaking compilation
-
-**Why**: This rule breaks practical patterns:
-```typescript
-// ❌ Rule would force this everywhere:
-interface Config {
-    readonly apiUrl: readonly string;
-    readonly timeout: readonly number;
-    readonly headers: readonly ReadonlyArray<readonly string>;
-}
-
-// ✅ We prefer developer choice:
-interface Config {
-    apiUrl: string;          // Immutable by convention
-    timeout: number;         // No need for readonly noise
-    readonly token: string;  // Explicitly readonly where it matters
-}
-```
-
-#### **Immutable Data: Incompatible with JavaScript**
-- `functional/immutable-data`: **OFF** - Fundamentally incompatible with normal JS/TS patterns
-
-**Why**: Even with exceptions, this rule fights against JavaScript's nature:
-```typescript
-// ❌ Rule complains about common patterns:
-const config = {};
-config.apiUrl = getApiUrl();      // Building objects incrementally
-config.timeout = getTimeout();    // Normal property assignment
-
-const results = [];
-for (const item of items) {
-    results.push(await process(item)); // Building arrays
-}
+# Find unused dependencies
+npx depcheck
 ```
 
-### **⚖️ Industry Comparison**
-
-Our approach aligns with **real-world usage** rather than theoretical purity:
-
-| Approach | forEach Usage | Immutability | Real Projects | Our Config |
-|----------|--------------|--------------|---------------|------------|
-| **Airbnb** | Prefers functional | Basic (`const`) | React, Netflix | ✅ Flexible |
-| **Google** | No preference | Basic (`const`) | Angular, Chrome | ✅ Flexible |
-| **Functional Purists** | Banned | Everything readonly | Few | ❌ Too rigid |
-
-**Popular Projects Using Pragmatic Approaches:**
-- **React**: Uses `forEach`, `for...of`, and mutable operations internally
-- **Vue**: Extensive use of mutable state and traditional loops
-- **Node.js**: Built on mutable patterns, uses all loop types
-- **TypeScript Compiler**: Uses traditional loops and mutable data structures
-
-### **🎨 When to Use What**
-
-**Use `forEach` when:**
-- Performing side effects on each element
-- The operation is simple and doesn't need early exit
-- You want clean, functional-looking code
+## 🚦 Usage Recommendations
 
-**Use `for...of` when:**
-- You need `break` or `continue`
-- Working with iterables (not just arrays)
-- You want cleaner syntax than traditional `for`
+### For Applications
+Use **Standard** preset - provides good balance of strictness and practicality.
 
-**Use traditional `for` when:**
-- You need the index
-- Performance is critical (marginally faster)
-- You're modifying the array during iteration
+### For Libraries
+Use **Library** preset - ensures clean public APIs and comprehensive documentation.
 
-**Use functional methods (`map`, `filter`, `reduce`) when:**
-- Transforming data immutably
-- Chaining operations
-- The intent is clearer than loops
+### For Maximum Code Quality
+Use **Aggressive** preset - comprehensive unused code detection.
 
-### **📊 The Numbers**
+## 🔍 Example Projects
 
-Based on analysis of top GitHub projects:
-- **70%** use mixed approaches (loops AND functional methods)
-- **25%** prefer functional style but still use loops when needed
-- **5%** attempt pure functional (often with heavy libraries)
-- **0%** successfully avoid all mutations in real applications
-
-**Conclusion**: This configuration reflects how **successful projects actually work**, not how theoretical articles say they should work.
-
-## 📈 Real Impact
-
-With all these rules enabled, this configuration catches:
-- **95%** of common JavaScript/TypeScript bugs
-- **100%** of promise-related errors
-- **100%** of null/undefined access errors
-- **90%** of infinite loop bugs
-- **100%** of precision loss bugs
-- **100%** of security issues from eval/Function
-
-The rules are based on real bugs found in production codebases and focus on pragmatic safety without dogma.
-
-## 📋 Code Style Overview
-
-### 🔧 Formatting Rules
-
-- **Brace Style**: Allman style (braces on new lines)
-- **Indentation**: Tabs (configurable tab width)
-- **Quotes**: Single quotes for strings
-- **Semicolons**: Required at statement ends
-- **Trailing Spaces**: Automatically removed
-
-### 📝 Before and After Examples
-
-#### Import Sorting
-```typescript
-// ❌ Before
-import { TypeResponse } from '../types';
-import type { SomeInterface } from './interfaces';
-import { EnumErrorCode } from '../enums';
-import type { BaseConfig } from '../config';
-
-// ✅ After (auto-fixed)
-import type { BaseConfig } from '../config';
-import type { SomeInterface } from './interfaces';
-import { EnumErrorCode } from '../enums';
-import { TypeResponse } from '../types';
-```
-
-#### Class Member Ordering
-```typescript
-// ❌ Before
-export class UserService
-{
-	private isInitialized = false;
-	public static VERSION = '1.0.0';
-	public name: string;
-	
-	private validateUser() { /* ... */ }
-	public async getUser() { /* ... */ }
-	public static getInstance() { /* ... */ }
-	constructor(name: string) { /* ... */ }
-}
-
-// ✅ After (auto-fixed)
-export class UserService
-{
-	public static VERSION = '1.0.0';
-	
-	public name: string;
-	private isInitialized = false;
-	
-	constructor(name: string) { /* ... */ }
-	
-	public static getInstance() { /* ... */ }
-	
-	public async getUser() { /* ... */ }
-	
-	private validateUser() { /* ... */ }
-}
-```
-
-#### JSDoc Documentation with Type Hints
-```typescript
-// ❌ Before - Missing JSDoc
-export function processUser(userData: UserData): ProcessedResult {
-    return process(userData);
-}
-
-// ⚠️ After (auto-fixed) - JSDoc block generated but missing type hints
-/**
- * 
- * @param userData
- * @returns
- */
-export function processUser(userData: UserData): ProcessedResult {
-    return process(userData);
-}
-
-// ❌ Still fails - Missing type hints and descriptions
-// ESLint errors:
-// - Missing JSDoc @param "userData" type
-// - Missing JSDoc @param "userData" description  
-// - Missing JSDoc @returns type
-// - Missing JSDoc block description
-
-// ✅ Complete JSDoc with type hints (must be added manually)
-/**
- * Processes user data and returns formatted result.
- * @param {UserData} userData - The user data to process
- * @returns {ProcessedResult} The processed user result
- */
-export function processUser(userData: UserData): ProcessedResult {
-    return process(userData);
-}
-
-// ⚠️ Note: ESLint cannot auto-generate type hints from TypeScript types.
-// Type annotations must be added manually to satisfy the linter requirements.
-```
+### React Application
+```javascript
+// eslint.config.mjs
+import config from '@dmitryrechkin/eslint-standard';
 
-#### JSDoc Alignment
-```typescript
-// ❌ Before
-/**
-   * Process user data
-   * @param userData - The user data
-   * @returns Processed result
-   */
-
-// ✅ After (auto-fixed)
-/**
- * Process user data
- * @param userData - The user data
- * @returns Processed result
- */
+export default config({
+	tsconfigPath: './tsconfig.json',
+	ignores: ['dist/**', 'build/**', 'public/**']
+});
 ```
 
-### 🏷️ Naming Conventions
-
-- **Variables & Functions**: `camelCase`
-- **Classes & Interfaces**: `PascalCase`
-- **Constants**: `UPPER_CASE` or `camelCase`
-- **Enum Members**: `UPPER_CASE` or `PascalCase`
-- **Type Parameters**: `PascalCase`
-
-### 📝 JSDoc with Type Hints Requirements
-
-This configuration requires comprehensive JSDoc documentation with type hints:
-
-- **Type Annotations Required**: All parameters and return values must include JSDoc type hints
-- **Description Required**: All functions, parameters, and return values must have descriptions
-- **Auto-generation Limited**: ESLint can generate JSDoc blocks but cannot infer TypeScript types
-- **Manual Completion Needed**: Type hints must be added manually after auto-generation
-
-#### Required JSDoc Format
-
+### TypeScript Library
 ```javascript
-/**
- * Function description is required.
- * @param {string} name - Parameter description is required
- * @param {number} age - Type hint {number} is required
- * @returns {string} Return type and description required
- */
-function greet(name: string, age: number): string {
-    return `Hello ${name}, you are ${age} years old`;
-}
-```
+// eslint.config.mjs
+import config from '@dmitryrechkin/eslint-standard/library';
 
-#### Common Type Hint Patterns
-
-```javascript
-// Basic types
-@param {string} name
-@param {number} count
-@param {boolean} isActive
-@param {Object} config
-@param {Array<string>} items
-@param {Function} callback
-
-// Complex types
-@param {UserData} userData - Custom type
-@param {Promise<Response>} response - Generic type
-@param {string|number} id - Union type
-@param {{name: string, age: number}} person - Object type
-@param {string[]} names - Array shorthand
-@returns {void} - For functions with no return
+export default config({
+	tsconfigPath: './tsconfig.json',
+	ignores: ['dist/**', 'examples/**']
+});
 ```
 
-#### Important Notes
-
-1. **ESLint Cannot Auto-Generate Types**: While ESLint can create JSDoc blocks, it cannot determine TypeScript types
-2. **Manual Work Required**: After running `--fix`, you must manually add all type hints
-3. **Duplication with TypeScript**: This approach duplicates type information already in TypeScript
-4. **Maintenance Overhead**: Types must be kept in sync between TypeScript and JSDoc
-
-## ⚠️ Troubleshooting
-
-### Peer Dependency Warnings
-
-If you see peer dependency warnings, install all required dependencies:
-```bash
-npm install eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin eslint-plugin-unused-imports @stylistic/eslint-plugin eslint-plugin-jsdoc eslint-plugin-simple-import-sort eslint-plugin-perfectionist --save-dev
+### Node.js API
+```javascript
+// eslint.config.mjs
+import config from '@dmitryrechkin/eslint-standard/aggressive';
+
+export default config({
+	tsconfigPath: './tsconfig.json',
+	rules: {
+		'no-console': 'off', // Allow console in Node.js
+	}
+});
 ```
 
-### ESLint Version Compatibility
-
-This package requires **ESLint 9+** for flat config support. For older ESLint versions, please use an earlier version of this package.
-
-### TypeScript Configuration
-
-Ensure your `tsconfig.json` is properly configured and the path specified in `tsconfigPath` is correct.
-
-## 🔧 Configuration Options
-
-The configuration function accepts these options:
-
-| Option | Type | Default | Description |
-|--------|------|---------|-------------|
-| `tsconfigPath` | `string` | `'./tsconfig.json'` | Path to your TypeScript config file |
-| `files` | `string[]` | `['**/*.{js,jsx,ts,tsx}']` | File patterns to lint |
-| `ignores` | `string[]` | `['node_modules/**', 'dist/**']` | Patterns to ignore |
-| `plugins` | `object` | `{}` | Additional ESLint plugins |
-| `rules` | `object` | `{}` | Additional or overridden rules |
-
-## 📚 Plugin Documentation
-
-This configuration uses several powerful ESLint plugins:
-
-- **[@typescript-eslint](https://typescript-eslint.io/)**: TypeScript-specific linting rules
-- **[eslint-plugin-perfectionist](https://perfectionist.dev/)**: Auto-sorting for classes, imports, and more
-- **[eslint-plugin-simple-import-sort](https://github.com/lydell/eslint-plugin-simple-import-sort)**: Simple and reliable import sorting
-- **[@stylistic/eslint-plugin](https://eslint.style/)**: Stylistic formatting rules
-- **[eslint-plugin-unused-imports](https://github.com/sweepline/eslint-plugin-unused-imports)**: Automatic unused import removal
-
 ## 🤝 Contributing
 
-Contributions to improve this ESLint configuration are welcome! Please feel free to:
-
-- 🐛 [Report bugs](https://github.com/dmitryrechkin/eslint-standard/issues)
-- 💡 [Suggest new features](https://github.com/dmitryrechkin/eslint-standard/issues)
-- 🔧 [Submit pull requests](https://github.com/dmitryrechkin/eslint-standard/pulls)
+Issues and pull requests are welcome on [GitHub](https://github.com/dmitryrechkin/eslint-standard).
 
 ## 📄 License
 
-MIT License - see the [LICENSE](LICENSE) file for details.
-
-
+MIT License - see LICENSE file for details.