How do their APIs compare?

Comparing "APIs" across these two projects means comparing quite different things — sentry-javascript exposes a family of SDK integration/instrumentation APIs across many runtimes, while Pinia exposes a small, focused state-management API for Vue. Here's a grounded comparison based on what's in the retrieved data:

Surface area and purpose

sentry-javascript is a multi-package SDK where the "API" is really many APIs, one per platform/framework, layered on a shared core:

• Framework-specific instrumentation, e.g. Angular's ErrorHandler extraction logic in [packages/angular/src/errorhandler.ts:L34-L55] and its [trace] directive in [packages/angular/src/tracing.ts:L253-L279].
• Server middleware that manipulates HTTP responses, e.g. Astro's streaming HTML injection in [packages/astro/src/server/middleware.ts:L445-L506] and URL decoding helpers in [packages/astro/src/server/middleware.ts:L378-L390].
• Low-level transport/protocol clients, e.g. the AWS Lambda Extension API client in [packages/aws-serverless/src/lambda-extension/aws-lambda-extension.ts:L1-L15].
• Browser performance/event utilities, e.g. getBrowserPerformanceAPI() in [packages/browser-utils/src/performance/utils.ts:L47-L55] and web-vitals helpers in [packages/browser-utils/src/web-vitals/utils.ts:L1-L24].
• Error normalization helpers like extractType() in [packages/browser/src/eventbuilder.ts:L179-L197].

This reflects the architecture signal from RepoPilot: a C-grade (67/100) import graph with 400 files, 1631 internal imports, and 8 cycles, with heavily-shared core files like packages/core/src/utils/debug-logger.ts (46 importers), packages/core/src/debug-build.ts (41 importers), packages/core/src/currentScopes.ts (38 importers), packages/core/src/types/span.ts (32 importers), and packages/core/src/client.ts (28 importers). The API design is inherently plugin/integration-based rather than a single cohesive interface.

Pinia exposes a much narrower, composable-oriented API centered on store definition and consumption:

• mapState / mapGetters / mapActions for Options API interop, mapping store getters/actions onto component computed/methods [packages/pinia/src/mapHelpers.ts:L252-L338, L339-L371, L372-L388].
• storeToRefs() for destructuring reactive state/getters out of a store while preserving reactivity, with careful type-level handling of readonly vs writable refs via _ToComputedRefs/_ToStateRefs [packages/pinia/src/storeToRefs.ts:L1-L86].
• Core Store<Id, S, G, A> type composing state, getters, and actions [packages/pinia/src/types.ts:L415-L487].
• setMapStoreSuffix() for customizing generated store property names [packages/pinia/src/mapHelpers.ts:L73-L102].
• Diagnostic/runtime-warning APIs, e.g. structured dev warnings like PINIA_R1006/PINIA_R1007 with why/fix/docs fields [packages/pinia/src/diagnostics.ts:L36-L52].

Style differences

• sentry-javascript's API is heavily side-effecting and environment-specific (patches HTTP responses, wraps error handlers, hooks into framework lifecycles). Functions like injectMetaTagsInResponse mutate/replace streams and forward errors to Sentry via sendErrorToSentry [packages/astro/src/server/middleware.ts:L445-L506].
• Pinia's API is declarative and type-driven, leaning on TypeScript conditional/mapped types (_IfEquals, _IsReadonly, _ToComputedRefs) to preserve strong typing through reactivity transformations [packages/pinia/src/storeToRefs.ts:L24-L60]. There's comparatively little runtime branching — most complexity is at the type level.
• Pinia also invests in developer-facing diagnostics as a first-class API surface (the diagnostics.ts war