Skip to content

New Terminal Execution Option #244

@KubrickCode

Description

@KubrickCode

New Terminal Execution Option - Analysis Result

🎯 Conclusion (TL;DR)

Selected Approach: Simple Boolean Option (newTerminal?: boolean)
Key Reason: Simple implementation, consistency with existing patterns (insertOnly, useVsCodeApi), guaranteed backward compatibility


📋 Problem Definition

Concrete Scenarios:

  • Case 1: Developer clicks npm test button, while reviewing results wants to run tests in parallel by clicking again → Currently re-executes in same terminal, losing previous output
  • Case 2: Want to monitor multiple containers simultaneously with long-running commands like docker logs -f → Currently limited to single terminal
  • Case 3: Want to compare outputs by running same command under different conditions → Terminal reuse prevents comparison

Current Problem: Button clicks reuse the same terminal, making parallel execution or output comparison impossible

Goal: Provide per-button "always run in new terminal" option for user choice


📦 Scope

Included:

  • Add newTerminal property to CommandButton type
  • Branch new terminal creation logic in TerminalManager
  • Add checkbox option in Configuration UI
  • Update package.json JSON Schema
  • Write related unit tests

Excluded:

  • Terminal instance limits (maxInstances)
  • Terminal pooling/recycling mechanism
  • Automatic terminal cleanup features

🔍 Solution Investigation

Approach 1: Simple Boolean Option

Method:

  • Add newTerminal?: boolean to CommandButton type
  • When true, create new terminal each time; when false (default), reuse as before
  • Provide as "Always create new terminal" checkbox in Configuration UI

Pros:

  • Simple implementation (1-2 days work)
  • Consistency with existing option patterns (insertOnly, useVsCodeApi)
  • Perfect backward compatibility (undefined = false)
  • Minimal user learning cost

Cons:

  • Terminals can grow indefinitely (user responsibility)
  • No fine-grained control (instance count limits, etc.)

Approach 2: Instance Limit Option

Method:

  • Add maxTerminalInstances?: number property
  • Reference VS Code Tasks' instanceLimit pattern
  • Create new terminals up to N, then reuse oldest when exceeded

Pros:

  • Prevents terminal explosion
  • Similar to VS Code native features

Cons:

  • Increased implementation complexity
  • Requires terminal tracking logic
  • Over-engineering for current requirements

Approach 3: Instance Policy Option

Method:

  • Add instancePolicy?: "reuse" | "new" | "prompt" property
  • "prompt" asks user for confirmation on each execution

Pros:

  • Maximum flexibility

Cons:

  • Excessive complexity
  • High user learning curve
  • Violates YAGNI principle

✅ Final Selection

Adopted: Approach 1 (Simple Boolean Option)

Selection Reason:

  • YAGNI Principle: Current request only needs "new terminal or not"
  • Consistency: Same boolean pattern as existing insertOnly, useVsCodeApi
  • Incremental Extension: Can extend to Approach 2/3 if needed later
  • Low Risk: Default false perfectly maintains existing behavior

Rejected Approaches:

  • Approach 2: Over-engineering for current requirements
  • Approach 3: Low value for complexity cost

🛠️ Implementation Method

Core Changes:

  1. Type Extension (src/shared/types.ts)

    • Add newTerminal?: boolean to CommandButton
    • Synchronize with CommandButtonWithOptionalId
  2. Terminal Logic Modification (src/internal/managers/terminal-manager.ts)

    • When newTerminal: true, create new terminal without Map storage
    • Existing reuse logic maintained for newTerminal: false/undefined
  3. Execution Chain Modification (src/internal/command-executor.ts)

    • Pass newTerminal flag in executeTerminalCommand
  4. Configuration Schema (package.json)

    • Define newTerminal property with description
  5. Configuration UI (src/view/src/components/command-form.tsx)

    • Add checkbox below Terminal Name field
    • Conditional display: Only when Execution Mode is Terminal

New Dependencies: None


⚙️ Key Considerations

  • Backward Compatibility: newTerminal declared as optional, works normally even if absent from existing config files
  • UI Placement: Below Terminal Name field, "Show only when Execution Mode is Terminal"
  • Terminal Naming: Use same name for new terminals (VS Code auto-adds numbers)
  • Special Cases:
    • When useVsCodeApi: true, no terminal used → newTerminal ignored
    • When executeAll: true (group execution), respect individual button's newTerminal option

🎯 Completion Criteria

Feature Verification:

  • Set newTerminal: true on button, click → Verify new terminal created each time
  • Set newTerminal: false (or unset) on button, click → Verify terminal reused as before
  • Toggle option in Configuration UI → Verify reflected in config file
  • Upgrade with existing config file (no newTerminal) → Verify normal operation
  • Execute executeAll group → Verify individual newTerminal options applied per button

Technical Implementation:

  • Add newTerminal?: boolean to CommandButton type
  • Add branch logic in TerminalManager.executeCommand
  • Pass flag in command-executor.ts
  • Update package.json JSON Schema
  • Add Configuration UI checkbox
  • Update i18n translation files (en.json, ko.json)
  • Write unit tests

❓ Needs Confirmation

Current Assumptions:

  • Property name: newTerminal (concise and clear)
  • Default value: false (maintain existing behavior)
  • UI label: "Always create new terminal" / "항상 새 터미널 생성"

If Needed:

Sub-issues

Metadata

Metadata

Assignees

Labels

featureNew featureimprovementImprovements to existing features

Projects

Status

Done

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions