[FEATURE] Installation via NPM registry

[davi-mplan]

It can be easily added as dependency on any TS project so no need to install another CLI tool manually on each dev machine.

[github-actions]

Triage decision

needs-design

Proposed labels

theme/portability
area/distribution
area/docs-site
type/feature
status/needs-design

Milestone

null

Suggested next action

Clarify the specific workflow: is the goal npm install -g apm-cli, npx @microsoft/apm install, or zero-install via npx wrapper? Share whether uvx apm-cli or pip install apm-cli already meets the need.

Suggested issue comment

Thanks for the feature request, `@davi-mplan`! Publishing APM to the NPM registry so TypeScript projects can consume it as a dependency is a valid distribution request -- tools like esbuild, Prettier, and Playwright have done this successfully.

Before committing to the implementation approach, we need to understand the specific use case better:

1. **What workflow are you aiming for?**
   - `npm install -g `@microsoft/apm-cli`` (global install for developers)?
   - `npx `@microsoft/apm-cli` install` (ad-hoc, no global install)?
   - `"devDependencies": { "`@microsoft/apm-cli`": "^0.9" }` in `package.json` (per-project pinning)?

2. **Would an existing option work?**
   APM is already installable via `pip install apm-cli` (Python) and as a standalone binary via `curl | sh` or the PowerShell installer. If your team has Python available, `uvx apm-cli` provides zero-install ad-hoc execution without a global install. Would any of these cover your workflow?

3. **Platform scope**: NPM distribution of a Python binary requires OS-specific sub-packages (like esbuild's model). Is this acceptable, or do you prefer a pure NPM package that calls `pip` internally?

With that context we can assess whether a npm wrapper, a PyPI re-distribution, or a simpler approach is the right answer.

Per-lens notes (collapsed)

DevX UX Expert -- User-Need Reviewer

The request body is 124 characters -- very thin. The user's stated goal is "add APM as a dependency on any TS project so no need to install another CLI tool manually on each dev machine." This maps to the distribution surface. The underlying need (zero-friction APM availability in TypeScript projects) is valid, but without knowing the specific workflow (global install vs. npx vs. per-project devDependency), it is not possible to evaluate the right implementation approach. Three distinct solutions have very different trade-offs.

Supply Chain Security Expert -- Risk-Surface Reviewer

Publishing to NPM introduces a new registry trust surface (npmjs.com). Binary-in-npm distribution (as esbuild does) requires OS-specific sub-packages, each of which is an independent NPM package in the organization namespace -- typosquatting risk on each one. Alternatively, an NPM wrapper that calls pip install at postinstall time introduces a Python dependency in a JS ecosystem, which is unexpected and likely to break in constrained CI environments. The design must specify exactly which distribution model is used and how the binary is verified after download.

OSS Growth Hacker -- Contributor-Tone Reviewer

davi-mplan has author_association=NONE on microsoft/apm and filed a very thin request. The reply should be warm and ask for clarification rather than dismissing the request. Acknowledge that the use case is valid and that there is prior art (esbuild, Playwright) for binary distribution via NPM. Give them concrete alternative options to evaluate (uvx, pip, curl) in case one already solves their problem. This kind of clarifying conversation often converts a thin request into a well-scoped contribution.

Python Architect -- Architecture Reviewer

NPM distribution of a Python CLI binary requires significant design work. The three implementation options each have different trade-offs: (a) NPM wrapper downloading the binary at postinstall -- supply chain risk, platform-specific; (b) self-contained NPM package with embedded binary -- large package sizes, complex cross-platform build pipeline; (c) uvx / PyPI -- simpler but requires Python. None of these is a "just do it" change; each requires release pipeline integration. needs-design with a clarification request is the right call.

Doc Writer -- Documentation Reviewer

If NPM distribution is implemented, the installation documentation needs a new "NPM / npx" section. area/docs-site as a secondary label ensures the implementing PR is reminded to update docs. The clarification response in the suggested comment will also help scope the documentation surface.

APM CEO -- Triage Arbiter

The request is too thin to commit architecture. NPM distribution is strategically attractive (lowers friction for TypeScript-heavy teams), but the implementation complexity is non-trivial and the use case is unclear. needs-design with a warm clarification request is the right call. If the user wants uvx apm-cli, that already works and requires no engineering. If they want a true npm install experience, the design work is substantial.

{
  "decision": "needs-design",
  "decision_detail": "Request body is too thin to determine the right implementation approach. Three distinct distribution models (global npm install, npx wrapper, per-project devDependency) have different trade-offs and the use case must be clarified first.",
  "theme": "theme/portability",
  "areas": ["area/distribution", "area/docs-site"],
  "type": "type/feature",
  "status": "status/needs-design",
  "priority": null,
  "preserved_labels": [],
  "milestone": null,
  "next_action": "Clarify the specific workflow (global install vs npx vs devDependency) and whether uvx apm-cli or pip install apm-cli already meets the need.",
  "comment_markdown": "Thanks for the feature request, `@davi-mplan`! Publishing APM to the NPM registry so TypeScript projects can consume it as a dependency is a valid distribution request -- tools like esbuild, Prettier, and Playwright have done this successfully.\n\nBefore committing to the implementation approach, we need to understand the specific use case better:\n\n1. **What workflow are you aiming for?**\n   - `npm install -g `@microsoft/apm-cli`` (global install for developers)?\n   - `npx `@microsoft/apm-cli` install` (ad-hoc, no global install)?\n   - `\"devDependencies\": { \"`@microsoft/apm-cli`\": \"^0.9\" }` in `package.json` (per-project pinning)?\n\n2. **Would an existing option work?**\n   APM is already installable via `pip install apm-cli` (Python) and as a standalone binary via `curl | sh` or the PowerShell installer. If your team has Python available, `uvx apm-cli` provides zero-install ad-hoc execution without a global install. Would any of these cover your workflow?\n\n3. **Platform scope**: NPM distribution of a Python binary requires OS-specific sub-packages (like esbuild's model). Is this acceptable, or do you prefer a pure NPM package that calls `pip` internally?\n\nWith that context we can assess whether a npm wrapper, a PyPI re-distribution, or a simpler approach is the right answer."
}

---

Triage status: agentic proposal pending human ratification.
Silence is approval. Maintainers can:

• Override any label or milestone above by editing it directly --
  human edits are authoritative and will not be reverted on
  subsequent runs.
• Re-trigger triage by applying the status/needs-triage label, or
  by removing status/triaged to enroll the issue in the next
  daily sweep.

Posted by the Triage Panel workflow. See .apm/skills/apm-triage-panel for the panel skill.

Generated by Triage Panel · ● 2.2M · ◷