[Feature] Refactor large source files exceeding 500 lines for better maintainability

Summary

Several source files in the project exceed 500-700 lines, making them difficult to maintain, test, and understand. These files could benefit from refactoring into smaller, more focused modules.

Files Over 500 Lines

705 lines: src/common/packager.ts
665 lines: src/extension/networkInspector/certificateProvider.ts
659 lines: src/extension/appLauncher.ts
553 lines: src/extension/exponent/exponentHelper.ts
505 lines: src/extension/rn-extension.ts

Problems with Large Files

1. Cognitive load: Hard to understand full scope of responsibilities
2. Testing complexity: Large files are harder to unit test comprehensively
3. Merge conflicts: More likely when multiple contributors work on same file
4. Single Responsibility Principle: Large files often have multiple concerns
5. Navigation: Difficult to find specific functionality
6. Refactoring risk: Changes have wider blast radius

Proposed Refactoring Strategy

Priority 1: packager.ts (705 lines)

Current responsibilities (likely):

• Packager lifecycle management
• Port management
• Status monitoring
• Output handling
• Configuration

Suggested split:

• packager/PackagerManager.ts - Core packager lifecycle
• packager/PackagerStatusMonitor.ts - Status checking
• packager/PackagerOutputHandler.ts - Output parsing
• packager/PackagerConfiguration.ts - Config management
• packager/PackagerPortManager.ts - Port allocation/detection

Priority 2: certificateProvider.ts (665 lines)

Suggested split:

• certificates/CertificateGenerator.ts - OpenSSL certificate generation
• certificates/CertificateInstaller.ts - Device installation logic
• certificates/CertificateStore.ts - Certificate storage/retrieval
• certificates/PlatformCertificateHandler.ts - Platform-specific logic

Priority 3: appLauncher.ts (659 lines)

Suggested split:

• launcher/AppLaunchCoordinator.ts - High-level orchestration
• launcher/PlatformLauncher.ts - Platform-specific launch logic
• launcher/LaunchConfiguration.ts - Configuration handling
• launcher/LaunchValidator.ts - Pre-launch validation

Priority 4: exponentHelper.ts (553 lines)

Suggested split:

• expo/ExpoProjectDetector.ts - Project type detection
• expo/ExpoConfigHandler.ts - app.json/eas.json handling
• expo/ExpoCommandRunner.ts - Expo CLI command execution
• expo/ExpoVersionManager.ts - Expo SDK version management

Priority 5: rn-extension.ts (505 lines)

Suggested split:

• extension/ExtensionActivator.ts - Activation logic
• extension/CommandRegistry.ts - Command registration
• extension/ExtensionLifecycle.ts - Lifecycle management
• extension/WorkspaceManager.ts - Workspace handling

Refactoring Principles

1. Extract Classes: One class per file when possible
2. Cohesive Responsibilities: Each file should have a single, clear purpose
3. Preserve Interfaces: Maintain public APIs to avoid breaking changes
4. Incremental Changes: Refactor one file at a time
5. Test Coverage: Add/update tests for extracted modules
6. Maintain Backwards Compatibility: Use facade pattern if needed

Benefits

• Improved testability: Smaller units are easier to test
• Better code organization: Clear separation of concerns
• Reduced complexity: Each file has narrower scope
• Easier maintenance: Smaller files are easier to understand
• Reduced merge conflicts: Changes touch fewer lines
• Improved reusability: Extracted modules can be reused

Implementation Approach

Phase 1: Analysis (Do not implement yet)

• Read and understand current file structure
• Identify natural boundaries and responsibilities
• Document public APIs and dependencies
• Plan extraction strategy

Phase 2: Extract Helpers

• Move static utility functions to separate files
• Extract constants and type definitions
• Create shared interfaces

Phase 3: Extract Classes

• One class per file
• Maintain original public API through index file
• Update imports

Phase 4: Reorganize

• Group related files into subdirectories
• Update import paths
• Add index files for clean imports

Example: Refactoring packager.ts

Before:

src/common/packager.ts (705 lines)
  - class Packager
  - class PackagerStatusIndicator
  - port management functions
  - output parsing utilities

After:

src/common/packager/
  - index.ts (exports public API)
  - PackagerManager.ts (core logic)
  - PackagerStatusMonitor.ts
  - PortManager.ts
  - OutputHandler.ts
  - types.ts (shared types)
  - constants.ts

Risks and Mitigation

Risk: Breaking existing code
Mitigation: Use index.ts to maintain original export structure

Risk: Incomplete refactoring
Mitigation: One file at a time, fully tested before moving to next

Risk: Over-engineering
Mitigation: Extract only when clear responsibility boundaries exist

Success Criteria

• All extracted files are under 300 lines
• Test coverage maintained or improved
• No breaking changes to public APIs
• Clear documentation of module responsibilities
• Improved code metrics (cyclomatic complexity, etc.)

References

• Largest files: Found via find src -name "*.ts" -exec wc -l {} \; | sort -rn
• Related: Single Responsibility Principle
• Similar refactoring: Network inspector manager (already well-structured)

Start by reading src/common/packager.ts and inspecting its public APIs, dependencies, and natural responsibility boundaries; use the listed find/wc command to confirm the current file sizes. A successful refactor would address the files incrementally, preserve public exports and behavior, keep extracted files under 300 lines, and maintain or improve test coverage without breaking changes.