lark-cli update incorrectly detects pnpm-installed CLI as npm-installed

[ForgottenR]

Bug Description

lark-cli update only recognizes two installation sources according to --help:

• npm install: runs npm install -g @larksuite/cli@<version>
• manual/other: shows GitHub Releases download URL

When @larksuite/cli is installed globally via pnpm, lark-cli update misdetects it as an npm installation and runs npm install -g @larksuite/cli@<version>. This installs a second copy under npm global (~/.nvm/.../bin/lark-cli) instead of updating the pnpm-managed copy (~/Library/pnpm/bin/lark-cli).

Environment

• lark-cli version: 1.0.60 (installed via pnpm add -g @larksuite/cli)
• pnpm version: 11.1.1
• Node.js version: 26.1.0 (via nvm)
• OS: macOS

Reproduction

1. Install globally via pnpm:

pnpm add -g @larksuite/cli@1.0.44

2. Run the self-updater:

lark-cli update

Actual result

• A new copy of lark-cli is installed under npm global, e.g. ~/.nvm/versions/node/v26.1.0/bin/lark-cli.
• The pnpm-managed copy remains at the old version.
• which -a lark-cli now returns two different paths with potentially different versions.

Expected result

lark-cli update should detect the actual package manager (pnpm) and run the equivalent upgrade command, e.g.:

pnpm add -g @larksuite/cli@<version>

Alternatively, it should at least fall back to manual/other and show the GitHub release URL instead of silently switching package managers.

Root cause analysis

The detection logic appears to check whether the binary path lies under node_modules/@larksuite/cli/bin/. Since both npm and pnpm install the package into a node_modules/@larksuite/cli layout, pnpm installations satisfy the same path pattern and are incorrectly classified as npm installations.

Evidence from the binary strings:

npm install -g %s@%s
Detects the installation method automatically:
  - npm install: runs npm install -g @larksuite/cli@<version>
  - manual/other: shows GitHub Releases download URL

There are no pnpm add -g or pnpm install -g branches.

Impact

• Users who prefer pnpm end up with duplicate, inconsistent lark-cli installations.
• The lark-cli update command cannot be trusted to keep the active binary up to date when pnpm is used.
• PATH order determines which version runs, leading to confusing behavior across shell sessions and VS Code extension host environments.

Workaround

For pnpm users, manually upgrade instead of using lark-cli update:

pnpm add -g @larksuite/cli@<version>

Then sync skills separately if needed:

pnpm dlx skills add larksuite/cli -y -g

[liangshuo-1]

Thanks for the detailed report — you're right that the detection only handles npm. We'll evaluate adding proper pnpm support.

[xiawiie]

Opened PR #1698 to address this: #1698

What changed:

• lark-cli update now detects pnpm-managed installations as a first-class install method instead of treating them as manual/other installs.
• The detector handles pnpm .pnpm global paths and pnpm command shims, and tracks pnpm availability separately from npm availability.
• When pnpm is detected and available, self-update now runs pnpm add -g @larksuite/cli@<version>.
• The existing self-replace, rollback, binary verification, skills sync, JSON output, and human-readable update flow are reused for both npm and pnpm.
• Help text, manual fallback guidance, permission hints, and verification failure reinstall hints now show pnpm-specific commands when pnpm is the detected installer.
• Added focused tests for pnpm detection, missing-pnpm fallback, shim detection, pnpm install invocation, JSON/human update output, --check, and manual install hints.

Validation performed:

• Passed: go test ./internal/selfupdate ./cmd/update
• Passed: go vet ./...
• Passed: gofmt -l .
• Passed: go mod tidy with no go.mod / go.sum diff
• Passed: go run github.com/golangci/golangci-lint/v2/cmd/golangci-lint@v2.1.6 run --new-from-rev=origin/main
• Passed: make script-test
• Passed: make examples-build
• Passed: dry-run/local E2E subset across ./tests/cli_e2e/...

Full gates were also attempted:

• make unit-test is blocked in this local environment by unrelated failures: one transient localhost dial failure in internal/event/consume that passed on rerun, plus shortcuts/minutes tests failing because this machine resolves example.com to 198.18.4.33, causing URL safety validation to reject fixture download URLs as local/internal.
• make integration-test builds successfully and runs dry-run/local tests, but live E2E is blocked by the current test credentials/scopes, including Base, Drive, Wiki, and user IM scope requirements.