[betegon]

Extracts the source analyzer from Toolkit #1658 into the optional @sentry/api/source-analysis entry. Consumers use the shared engine with their own source and the published operation catalog:

import { operations } from "@sentry/api/operations";
import { analyzeSourceApiUsage } from "@sentry/api/source-analysis";

const analysis = analyzeSourceApiUsage(sources, operations, {
  queryParameters: ["dataset", "query"],
});
// A helper calling listOrganizationEvents with dataset="logs"
// retains that operation and its known query context.

Follows named/default imports, relative files, directory indexes, re-exports and helpers. Default identifier exports preserve wrapper/factory identity and call-site query context while retaining their public export summaries. Factory/wrapper conventions and boolean markers are explicit inputs; CLI routes and destructive-command policy stay in Toolkit.

The analyzer ships with the SDK and runs during each consumer's build. TypeScript is an optional peer isolated from the client, browser and catalog entries. Class/member dispatch and advanced module resolution remain outside its documented scope.

Validated: build, typecheck, 234 SDK tests and 2 Node tests, including packed imports and NodeNext types. A temporary adapter against the packed SDK passed 35 Toolkit tests and preserved existing command/API relationships across 535 source files and 136 command exports. CLI adoption follows the SDK release.

Closes #114 (v1.0 subissue).

[cursor]

Stale Bugbot comment from a previous run.

[sentry-junior]

Nice extraction overall: build, typecheck and all 179 tests pass locally, and the entry stays isolated from the root bundle. I probed the built dist/source-analysis.js against the real operation catalog and found two problems worth fixing before this ships as a public entry:

• A shorthand method gets reported as GET. In property(), a ShorthandPropertyAssignment returns initializer(file, member.name), which is undefined when the name is a parameter. Callers read undefined as "absent", so the request falls back to defaultMethod. Repro: with requests: [{ functionName: "apiRequest", pathArgument: 0, optionsArgument: 1 }], the code function call(method) { return apiRequest(/projects/${o}/${p}/, { method }); } resolves to GET getProject with methods: ["GET"]. The equivalent { method: method } correctly yields "Dynamic request identity". Since methods is what consumers use for destructive-command policy, a dynamic DELETE showing up as a read is the wrong way to fail. Fix: return member.name (or initializer(...) ?? null) so the existing unknown/null handling applies. Add a test next to the trailing-spread case.
• Unsupported module shapes drop edges with no diagnostic. sourceModule only maps .js to .ts/.tsx, so extensionless ("./a") and directory ("./lib") imports, which are common under bundler resolution, don't resolve. A helper calling an SDK operation through them ends up with empty usage. The same happens for default imports and exports and for class methods. The Toolkit parity run works because that code uses explicit .js specifiers, but other consumers will get false negatives that look exactly like "no API usage". The README says ambiguity produces diagnostics, so either resolve the common candidates (.ts, .tsx, /index.ts, /index.tsx) or report relative imports that don't match any supplied source, and document the supported shapes (named and namespace imports only, top-level functions and consts).

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit e50c287. Configure here.}

Addressed in follow-up review.