Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#2,950 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tái cấu trúc
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
typescript
Lĩnh vực
developer-experience, tooling

Hướng nghiên cứu

Bắt đầu bằng cách đọc src/common/packager.ts và kiểm tra các API công khai, các dependency cũng như ranh giới trách nhiệm tự nhiên của nó; sử dụng lệnh find/wc được liệt kê để xác nhận kích thước hiện tại của các tệp. Một lần refactor thành công sẽ xử lý các tệp theo từng bước, giữ nguyên các export công khai và hành vi, giữ các tệp được tách ra dưới 300 dòng, đồng thời duy trì hoặc cải thiện độ bao phủ kiểm thử mà không gây ra breaking changes.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

enhancement follow-up

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)
Ngôn ngữ chính
TypeScript
Star
2.7k
Fork
298
Merge trung bình
15 giờ 2 phút
Pull request đã merge (30 ngày)
28

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của microsoft/vscode-react-native

Tất cả issue của microsoft/vscode-react-native

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.