Feature request: Use system-installed wakatime-cli if available

[Anohoshi]

In the current implementation, the extension always downloads its own wakatime-cli binary on first run, regardless of whether the user already has it installed system-wide. This causes several issues:

1. Duplication: If the user already has wakatime-cli installed via their OS package manager, the extension still downloads its own copy, wasting disk space.
2. Compatibility issues: On some Linux distributions (e.g., NixOS, as well as certain containerized environments), the downloaded binary may not be executable due to differences in system libraries or the dynamic linker.
3. Update complexity: The user cannot manage wakatime-cli versions through their system package manager and must rely on the extension's update mechanism.
4. Offline/restricted environments: If the user works offline or behind a restrictive firewall, the extension fails to download the binary, making it useless even though a system wakatime-cli may already be present.

I propose changing the extension's logic as follows:

1. On initialization, the extension first checks whether the wakatime-cli executable is available in the user's PATH.
2. If found, the extension uses that system binary without downloading its own copy.
3. If not found, the extension falls back to downloading its own version, as it does now.

This approach would:

• Eliminate duplication and save disk space.

• Ensure compatibility with environments where the user has already ensured a working binary.

• Give users control over version and updates through their standard OS mechanisms.

• Allow offline use if wakatime-cli is already installed.

An additional option could be to add a configuration setting where the user can manually specify the path to wakatime-cli (with a default of looking in PATH). This would be even more flexible and cover cases where the binary is installed in a non‑standard location.

For example, Zed already supports a similar mechanism for LSP servers. Users can specify a custom binary path in their settings like this:

"lsp": {
  "clangd": {
    "binary": {
      "ignore_system_version": false,
      "path": "/run/current-system/sw/bin/clangd"
    }
  }
}

A similar configuration option ("wakatime_cli_path") could be added for this extension, allowing users to point to a system‑wide installation.

Additional context

• This approach is already used in many other WakaTime plugins for editors such as VSCode, Sublime Text, and IntelliJ — they first look for a system‑wide wakatime-cli and only download their own if it is missing.

• It is a standard practice for plugins that integrate with external CLI tools and significantly improves user experience.

This change would require only a small modification to the initialization code — checking PATH and falling back to the download if needed.

[bestgopher]

I have considered this approach, but this extension may rely heavily on new features and command-line options in the latest version of wakatime-cli. Therefore, I think using the latest version of wakatime-cli could help avoid many compatibility issues. What do you think?

[Anohoshi]

@bestgopher I understand the compatibility concern. A version check could be added: use the system wakatime-cli only if its version meets a minimum required version (defined in the extension). Otherwise, fall back to the bundled download. This would solve the issue for all environments without breaking anything. What do you think?

[bestgopher]

@Anohoshi That’s a great idea. Would you be able to open a PR to implement it?

[Anohoshi]

@bestgopher , I don't have enough Rust experience to write this PR myself, unfortunately.