Feature: Command parser for npm/pip/brew install

[ProduktEntdecker]

Overview

Parse package manager install commands and extract package names with versions.

Depends On

• Pivot: CLI hook scaffold replacing MCP server #1 (CLI scaffold)

Acceptance Criteria

• Detect npm install, npm i, npm add commands
• Detect pip install, pip3 install commands
• Detect brew install commands
• Extract package name and version (e.g., lodash@4.17.0 → name: lodash, version: 4.17.0)
• Handle multiple packages in one command
• Handle flags (--save-dev, -D, etc.) without breaking parsing
• Return null/skip for non-install commands

Examples

Input	Output
npm install lodash@4.17.0	[{name: 'lodash', version: '4.17.0'}]
npm i express react	[{name: 'express'}, {name: 'react'}]
pip install requests==2.28.0	[{name: 'requests', version: '2.28.0'}]
brew install wget	[{name: 'wget'}]
npm run build	null (not an install)

Priority: P0

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

✅ Successfully generated implementation plan.

💡 Use @coderabbitai <feedback> to replan

Examples

• Example 1
• Example 2

---

🔗 Similar Issues

Related Issues

• Feature: OSV API integration for vulnerability checks #3
• Test: Unit tests for parser and decision engine #6

👤 Suggested Assignees

• ProduktEntdecker

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[coderabbitai]

Coding Plan

Approach

Add a command parsing capability to the MCP server that can accept package manager install commands (npm, pip, brew) as input and extract structured package information (names and versions) from them.

Observations

The project is an MCP (Model Context Protocol) server called "patchpilot-mcp" that currently provides vulnerability scanning for npm packages. It uses the @modelcontextprotocol/sdk framework with one registered tool (check_package) that validates inputs using Zod schemas. The codebase follows a minimal structure with types in src/types/, helper utilities co-located with type definitions, and all MCP tool registration in src/index.ts. The application communicates via MCP protocol rather than traditional CLI argument parsing.

Assumptions

Assumption 1: Tool Interface Design

Options Considered:

• Add a new MCP tool that accepts command strings and returns parsed packages
• Extend the existing check_package tool to accept either structured input or command strings
• Create multiple tools, one for each package manager (npm, pip, brew)

Chosen Option: 1

Rationale: Adding a focused parse_install_command tool follows the MCP pattern of atomic, single-responsibility tools and aligns with web search guidance on structured tool operations.

Assumption 2: Parser Module Location

Options Considered:

• Create src/utils/commandParser.ts for parsing utilities
• Create src/parsers/installCommand.ts for domain-specific parsing
• Add parsing logic inline in src/index.ts within the tool handler

Chosen Option: 2

Rationale: Creating a dedicated parsers directory follows the established pattern of organizing code by responsibility and makes the parser logic reusable if needed elsewhere.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Type Definitions and Data Structures

Define the types and interfaces needed to represent parsed command data and establish the contract for the parser.

Create Command Parser Types

Define types for parsed package information and command parsing results.

• Create src/types/command.ts to house command parsing types
• Define PackageManager type as discriminated union: 'npm' | 'pip' | 'brew'
• Define ParsedPackage interface with optional name and version fields (both strings)
• Define ParseCommandResult type as either ParsedPackage[] or null for non-install commands
• Follow existing naming conventions from src/types/osv.ts (PascalCase, semantic names)

🤖 Prompt for AI agents

Define the type system for command parsing to establish contracts for parsed
package data.

Create `src/types/command.ts` with:
- `PackageManager` type as union: 'npm' | 'pip' | 'brew'
- `ParsedPackage` interface with optional `name` and `version` string fields
- `ParseCommandResult` type as `ParsedPackage[] | null`
- Follow PascalCase naming conventions from existing types

Phase 2: Command Parser Implementation

Build the core parsing logic to detect package manager commands, extract package names and versions, and handle edge cases.

Task 1: Create Parser Module

Implement the command parsing utility that handles different package manager syntaxes.

• Create src/parsers/installCommand.ts as the parser module
• Export a main function parseInstallCommand(command: string): ParseCommandResult
• Implement detection for npm commands: 'npm install', 'npm i', 'npm add'
• Implement detection for pip commands: 'pip install', 'pip3 install'
• Implement detection for brew commands: 'brew install'
• Return null early if the command doesn't match any install pattern

Task 2: Implement Package Extraction Logic

Add logic to extract individual packages from the command arguments.

• Split command into tokens after the install subcommand
• Filter out common flags: '--save-dev', '-D', '--global', '-g', '--save', '-S', '--production', '-P', etc.
• For npm packages, handle @ version separator (e.g., lodash@4.17.0)
• For pip packages, handle == version separator (e.g., requests==2.28.0)
• For brew packages, treat entire token as package name (no version support in brew install command syntax)
• Handle scoped npm packages correctly (e.g., @types/node@18.0.0)
• Return array of ParsedPackage objects with extracted name and version fields

Task 3: Add Input Validation and Edge Case Handling

Ensure the parser handles malformed or edge case inputs gracefully.

• Add validation to handle empty strings, strings with only whitespace
• Handle commands with multiple spaces between tokens
• Ensure parser doesn't break on packages without versions
• Handle mixed packages (some with versions, some without) in the same command
• Add defensive checks for malformed version separators (e.g., lodash@ with no version)

🤖 Prompt for AI agents

Implement the core command parsing logic to extract package information from
install commands.

Create `src/parsers/installCommand.ts` with:
- Export `parseInstallCommand(command: string): ParseCommandResult` function
- Detect npm ('npm install', 'npm i', 'npm add'), pip ('pip install', 'pip3
install'), and brew ('brew install') commands
- Return null for non-install commands
- Split command into tokens and filter out flags (--save-dev, -D, --global, -g,
--save, -S, --production, -P, etc.)
- Extract packages with versions using:
  - `@` separator for npm (handle scoped packages like @types/node@18.0.0)
  - `==` separator for pip
  - No version separator for brew
- Handle edge cases: empty strings, whitespace, multiple spaces, packages
without versions, malformed separators
- Return array of ParsedPackage objects with name and optional version

Phase 3: MCP Tool Integration

Register the new parsing tool with the MCP server and connect it to the parser implementation.

Task 1: Register parse_install_command Tool

Add the new MCP tool to the server with appropriate input schema and handler.

• In src/index.ts, import the parser function and command types
• Register a new tool named parse_install_command using server.registerTool()
• Define Zod input schema with a single command field (string, min 1 character, max 1000 characters)
• Add description to the schema explaining the tool accepts package manager install commands

Task 2: Implement Tool Handler and Output Formatting

Connect the parser to the tool handler and format results according to MCP patterns.

• In the tool handler, call parseInstallCommand(command) with the validated input
• For null results (non-install commands), return formatted message: "Not an install command"
• For successful parses, format the array of packages as a structured text output
• Follow existing output format pattern from check_package: return object with content array containing text type
• Use try-catch to handle any parsing errors and return error response with isError: true flag
• Format package output clearly, showing name and version for each package (e.g., "Found 2 packages:\n- lodash@4.17.0\n- express (no version specified)")

🤖 Prompt for AI agents

Integrate the parser as a new MCP tool in the server.

In `src/index.ts`:
- Import parser function and command types
- Register `parse_install_command` tool using `server.registerTool()`
- Define Zod schema with `command` field (string, min 1, max 1000 chars)
- Add description explaining the tool accepts package manager install commands
- Implement handler that calls `parseInstallCommand(command)`
- For null results, return "Not an install command" message
- For successful parses, format output as structured text showing packages with
versions
- Follow existing `check_package` output pattern with content array
- Wrap in try-catch and return error response with `isError: true` on failures
- Format output like: "Found 2 packages:\n- lodash@4.17.0\n- express (no version
specified)"

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Define the type system for command parsing to establish contracts for parsed
package data.

Create `src/types/command.ts` with:
- `PackageManager` type as union: 'npm' | 'pip' | 'brew'
- `ParsedPackage` interface with optional `name` and `version` string fields
- `ParseCommandResult` type as `ParsedPackage[] | null`
- Follow PascalCase naming conventions from existing types
===============================================================================

Task: 2

Implement the core command parsing logic to extract package information from
install commands.

Create `src/parsers/installCommand.ts` with:
- Export `parseInstallCommand(command: string): ParseCommandResult` function
- Detect npm ('npm install', 'npm i', 'npm add'), pip ('pip install', 'pip3
install'), and brew ('brew install') commands
- Return null for non-install commands
- Split command into tokens and filter out flags (--save-dev, -D, --global, -g,
--save, -S, --production, -P, etc.)
- Extract packages with versions using:
  - `@` separator for npm (handle scoped packages like @types/node@18.0.0)
  - `==` separator for pip
  - No version separator for brew
- Handle edge cases: empty strings, whitespace, multiple spaces, packages
without versions, malformed separators
- Return array of ParsedPackage objects with name and optional version
===============================================================================

Task: 3

Integrate the parser as a new MCP tool in the server.

In `src/index.ts`:
- Import parser function and command types
- Register `parse_install_command` tool using `server.registerTool()`
- Define Zod schema with `command` field (string, min 1, max 1000 chars)
- Add description explaining the tool accepts package manager install commands
- Implement handler that calls `parseInstallCommand(command)`
- For null results, return "Not an install command" message
- For successful parses, format output as structured text showing packages with
versions
- Follow existing `check_package` output pattern with content array
- Wrap in try-catch and return error response with `isError: true` on failures
- Format output like: "Found 2 packages:\n- lodash@4.17.0\n- express (no version
specified)"

💡 Iterate on the plan with: @coderabbitai <feedback>

Example Feedback
- @coderabbitai You can skip phase 3. Add a simple unit test case for phase 2.
- @coderabbitai For assumption 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!