-
-
Notifications
You must be signed in to change notification settings - Fork 0
Description
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 testbutton, 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
newTerminalproperty toCommandButtontype - Branch new terminal creation logic in
TerminalManager - Add checkbox option in Configuration UI
- Update
package.jsonJSON 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?: booleantoCommandButtontype - When
true, create new terminal each time; whenfalse(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?: numberproperty - Reference VS Code Tasks'
instanceLimitpattern - 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
falseperfectly maintains existing behavior
Rejected Approaches:
- Approach 2: Over-engineering for current requirements
- Approach 3: Low value for complexity cost
🛠️ Implementation Method
Core Changes:
-
Type Extension (
src/shared/types.ts)- Add
newTerminal?: booleantoCommandButton - Synchronize with
CommandButtonWithOptionalId
- Add
-
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
- When
-
Execution Chain Modification (
src/internal/command-executor.ts)- Pass
newTerminalflag inexecuteTerminalCommand
- Pass
-
Configuration Schema (
package.json)- Define
newTerminalproperty with description
- Define
-
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:
newTerminaldeclared 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 →newTerminalignored - When
executeAll: true(group execution), respect individual button'snewTerminaloption
- When
🎯 Completion Criteria
Feature Verification:
- Set
newTerminal: trueon 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
executeAllgroup → Verify individualnewTerminaloptions applied per button
Technical Implementation:
- Add
newTerminal?: booleantoCommandButtontype - Add branch logic in
TerminalManager.executeCommand - Pass flag in
command-executor.ts - Update
package.jsonJSON 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:
- Whether to auto-add index to terminal name (e.g., "Test Runner Inconvenient issue of only supporting English when using shortcut keys #1", "Test Runner Thinking about how to clean up the opened terminals #2")
Sub-issues
Metadata
Metadata
Assignees
Labels
Projects
Status