Files
low-code-react-app-b/docs/LINTING_STATUS.md
2026-01-17 20:41:48 +00:00

3.8 KiB

Linting Status & Cleanup Plan

Current Status

Total Warnings: 525

The codebase currently has 525 ESLint/TypeScript warnings across the project. These are warnings, not errors, meaning the application builds and runs successfully.

Warning Categories

1. TypeScript any Types (Most Common - ~300 warnings)

Issue: @typescript-eslint/no-explicit-any Files Affected: Nearly all files with type annotations Priority: Medium Reason: The app uses a highly dynamic JSON-driven architecture where strict typing is challenging

Strategy:

  • Create proper TypeScript interfaces for JSON schemas
  • Use unknown instead of any where appropriate
  • Add type guards for runtime validation
  • Consider using Record<string, unknown> for truly dynamic objects

2. Unused Variables/Imports (~100 warnings)

Issue: @typescript-eslint/no-unused-vars Files Affected: Throughout the codebase Priority: High (easy wins) Examples:

  • Unused imports like Toaster, CardContent, Label
  • Unused destructured values
  • Unused function parameters

Strategy:

  • Remove unused imports
  • Prefix unused parameters with _ (e.g., _config, _index)
  • Remove dead code

3. React Hooks Dependencies (~50 warnings)

Issue: react-hooks/exhaustive-deps Files Affected: Components with useEffect, useCallback, useMemo Priority: Medium-High (can cause bugs)

Strategy:

  • Add missing dependencies
  • Use useCallback for function dependencies
  • Wrap objects/arrays in useMemo
  • Carefully evaluate exhaustive-deps warnings (some may be intentional)

4. Fast Refresh Export Issues (~15 warnings)

Issue: react-refresh/only-export-components Files Affected: UI component files that also export constants Priority: Low (doesn't affect production)

Strategy:

  • Move constants to separate files
  • Use allowConstantExport (already enabled in config)

5. Specific File Issues

  • Empty catch blocks (use comment or remove console.log) - FIXED
  • Naming conflicts (EmptyState, LoadingState, StatCard) - FIXED
  • Missing type definitions in orchestration/JSON-UI systems

Pragmatic Approach

Given the codebase is a low-code/no-code platform that generates code, many any types are justifiable:

  • JSON schemas are inherently dynamic
  • Component props are defined at runtime
  • The system needs flexibility for code generation

Cleanup Phases

Phase 1: Quick Wins (Completed)

  • Fix naming conflicts in component exports
  • Remove empty catch blocks with unused error variables
  • Remove unused imports (automated with IDE)
  • Prefix unused args with underscore

Phase 2: Type Safety

  • Create comprehensive interfaces for JSON schemas
  • Replace any with unknown in data sources
  • Add type guards for runtime validation
  • Define proper types for component registry

Phase 3: React Best Practices

  • Fix exhaustive-deps warnings
  • Optimize re-renders with proper memoization
  • Extract constants from component files

Phase 4: Architecture

  • Consider using Zod schemas for runtime validation
  • Generate TypeScript types from JSON schemas
  • Implement stricter typing in orchestration layer

Notes

  • Warnings are currently set to not fail the build (they're warnings, not errors)
  • The app functions correctly despite these warnings
  • Many warnings are inherent to the flexible/dynamic nature of the platform
  • Prioritize fixing warnings that could cause actual bugs (hooks deps, unused vars)

CI/CD Linting

Current lint job shows warnings but doesn't fail. Consider:

  1. Keeping current behavior (warnings only)
  2. OR: Setting error threshold (fail if > X warnings)
  3. OR: Making specific rules errors (e.g., no-unused-vars)
  • eslint.config.js - ESLint configuration
  • .github/workflows/lint.yml - CI lint workflow