vitejs / vitejs/launch-editor

IDE forks break if CLI package is not installed

Open
#102 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
JavaScript
Stars
721
Forks
94
Avg merge
2h 11m
Merged PRs (30d)
5

Description

In guess.js, the detection logic assumes that if an editor app is running, its CLI is available:

// Find editor by exact match.
if (processList.includes(processName)) {
  return [COMMON_EDITORS_MACOS[processName]]  // ← Returns 'cursor' without verification
}

In the case of many VSCode forks, such as Cursor IDE or Windsurf, the consumer may not have their CLI installed, instead using the VSCode command that they are used to.

Steps to Reproduce

  1. Install Cursor IDE app (but don't install the CLI command)
  2. Have Cursor app running
  3. Use launch-editor (e.g., through Vite dev server's /__open-in-editor endpoint)
  4. guessEditor detects Cursor process and returns ['cursor']
  5. childProcess.spawn('cursor', ...) fails with ENOENT: spawn cursor ENOENT
  6. Error shown to user with no fallback to VS Code or other available editors
Could not open index.tsx in the editor.
The editor process exited with an error: spawn cursor ENOENT ('cursor' command does not exist in 'PATH').

Proposed Solution

Add CLI verification and fall back to common editors when detected ones fail:

// Try detected running editors first
if (processList.includes(processName)) {
  const editorBin = COMMON_EDITORS_MACOS[processName]
  // check if CLI is installed, alternatively, check if it's a fork somehow?
}

// use fallback if CLI is not installed

Questions

  1. Would you accept a PR for this fix? I'd be happy to look into it.
  2. Are there existing test conventions I should follow?

Workaround

Users can set LAUNCH_EDITOR=code to bypass the detection and use VS Code directly.

Environment

  • OS: macOS
  • Node.js: v22.14
  • launch-editor: uses the package from a middleware in vite

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in guess.js and reproduce the failure through launch-editor's /__open-in-editor endpoint with Cursor running and its CLI absent. Trace how guessEditor selects the detected editor and how childProcess.spawn handles it. Done means an unavailable fork CLI no longer produces an ENOENT failure without trying an available fallback.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, nodejs
Domain
cli, devtools
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.