Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

[Feature] Improve type safety by reducing 'any' type usage in CDP message handlers

Fermée
#2,948 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@ConnorQi01 y travaille déjà.

Depuis le 13/10/2026.

  • #3000 par @ConnorQi01 — ouverte

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
typescript

Piste de recherche

Commencez par lire les handlers sous src/cdp-proxy/CDPMessageHandlers/ et l’interface ICDPMessageHandler, puis vérifiez si des types de protocole CDP existants sont disponibles. Définissez progressivement des types pour les formes de messages indiquées, ajoutez des guards lorsque nécessaire et mettez à jour les handlers afin de remplacer les utilisations de any identifiées, tout en préservant leurs messages traités et leur comportement.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

enhancement follow-up

Summary

The CDP (Chrome DevTools Protocol) message handler files use any type extensively, reducing type safety and making the code harder to maintain and debug.

Current Situation

High usage of any type in CDP handlers:

src/cdp-proxy/CDPMessageHandlers/hermesCDPMessageHandler.ts:
- processDebuggerCDPMessage(event: any)
- processApplicationCDPMessage(event: any)
- handleCallFunctionOnEvent(event: any): any
- handleFunctionTypeResult(event: any): any
- handlePausedEvent(event: any): any
- handleBreakpointSetting(event: any): any

src/cdp-proxy/CDPMessageHandlers/iOSDirectCDPMessageHandler.ts:
- processDebuggerCDPMessage(event: any)
- processApplicationCDPMessage(event: any)
- processDeprecatedConsoleMessage(event: any)
- params: any = {}

src/cdp-proxy/CDPMessageHandlers/rnCDPMessageHandler.ts:
- processDebuggerCDPMessage(event: any)
- processApplicationCDPMessage(event: any)
- handleAppBundleFirstPauseEvent(event: IProtocolCommand): any
- params: any = event.params

Interface definition:

interface ICDPMessageHandler {
    processDebuggerCDPMessage: (event: any) => ProcessedCDPMessage;
    processApplicationCDPMessage: (event: any) => ProcessedCDPMessage;
}

Problems with Current Approach

  1. No compile-time type checking: Can't catch CDP message structure errors at build time
  2. Poor IntelliSense: No autocomplete for CDP message properties
  3. Runtime errors: Easy to access non-existent properties without warning
  4. Maintainability: Harder to understand expected message structure
  5. Refactoring risk: Changes can break code without TypeScript catching it

Proposed Changes

Phase 1: Define CDP Message Types

Create type definitions for CDP protocol messages:

// cdp-proxy/types/CDPMessages.ts

interface CDPEvent {
    method: string;
    params?: Record<string, unknown>;
}

interface CDPCallFunctionOnEvent extends CDPEvent {
    method: 'Runtime.callFunctionOn';
    params: {
        functionDeclaration: string;
        objectId?: string;
        arguments?: any[];
        returnByValue?: boolean;
    };
}

interface CDPPausedEvent extends CDPEvent {
    method: 'Debugger.paused';
    params: {
        callFrames: CallFrame[];
        reason: string;
        data?: Record<string, unknown>;
    };
}

interface CallFrame {
    callFrameId: string;
    functionName: string;
    location: Location;
    scopeChain: Scope[];
}

// ... more type definitions
Phase 2: Update Handler Interfaces

Replace any with proper types:

interface ICDPMessageHandler {
    processDebuggerCDPMessage: (event: CDPEvent) => ProcessedCDPMessage;
    processApplicationCDPMessage: (event: CDPEvent) => ProcessedCDPMessage;
}
Phase 3: Add Type Guards

Implement type guards for runtime type checking:

function isCDPCallFunctionOnEvent(event: CDPEvent): event is CDPCallFunctionOnEvent {
    return event.method === 'Runtime.callFunctionOn';
}

function isCDPPausedEvent(event: CDPEvent): event is CDPPausedEvent {
    return event.method === 'Debugger.paused';
}
Phase 4: Update Handler Implementations

Use type guards in handlers:

public processDebuggerCDPMessage(event: CDPEvent): ProcessedCDPMessage {
    if (isCDPCallFunctionOnEvent(event)) {
        return this.handleCallFunctionOnEvent(event);
    }
    if (isCDPPausedEvent(event)) {
        return this.handlePausedEvent(event);
    }
    // ...
}

private handleCallFunctionOnEvent(event: CDPCallFunctionOnEvent): ProcessedCDPMessage {
    // event.params is now properly typed
    const { functionDeclaration, objectId } = event.params;
    // ...
}

Benefits

  • Type safety: Catch CDP message structure errors at compile time
  • Better IntelliSense: Autocomplete for CDP message properties
  • Self-documenting: Types serve as documentation for CDP protocol usage
  • Refactoring safety: TypeScript catches breaking changes
  • Debugging: Easier to identify message structure issues
  • Maintenance: Clearer code intent and expected structures

Implementation Strategy

  1. Start with commonly used CDP message types
  2. Add type definitions incrementally (one handler at a time)
  3. Use union types for messages with variants
  4. Leverage TypeScript's discriminated unions for type narrowing
  5. Consider using existing CDP protocol type definitions if available

Potential Challenges

  • CDP protocol has many message types
  • Some messages have dynamic/flexible structures
  • Need to balance type safety with flexibility
  • Requires understanding CDP protocol specification

Alternative Approaches

  1. Use @types/chrome-devtools-protocol: Leverage existing type definitions
  2. Generate types from protocol JSON: Use CDP protocol specification
  3. Gradual typing: Start with loose types, refine incrementally
  4. Unknown over any: Use unknown instead of any for better safety

References

Langage dominant
TypeScript
Étoiles
2.7k
Forks
298
Merge moyen
18 h 34 min
PR mergées (30 j)
30

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de microsoft/vscode-react-native

Toutes les issues de microsoft/vscode-react-native

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.