How do their APIs compare?

These two projects have fundamentally different purposes and API shapes, so a direct comparison is mostly about contrasting design intent rather than overlapping surface area.

airbnb/react-sketchapp: a rendering API

react-sketchapp's public API is a React renderer — its job is to take React component trees and turn them into Sketch document JSON. The core surface is:

• render(<Component/>, container) — the entry point shown in the README, analogous to ReactDOM.render, but targeting a Sketch page/artboard instead of the DOM.
• Component primitives like Text, Artboard, View, Svg, and symbol-related components (SymbolMaster/SymbolInstance). The SymbolInstanceRenderer class, for example, exposes renderGroupLayer to resolve a symbol's overrides into a Sketch symbolInstance JSON node, including validation like the dimension-matching check when a nested symbol is overridden [src/renderers/SymbolInstanceRenderer.ts:L100-L154].
• A Platform module mirroring React Native's Platform API shape (Platform.OS, Platform.Version, Platform.select) so code can branch on the fact that it's running inside Sketch [src/Platform.ts:L1-L8].
• Style-to-JSON transforms (not really "API" in the public sense, but the internal surface most code depends on) — functions like the shadow-building logic in jsonUtils/style.ts that convert React-style style objects into Sketch's FileFormat.Shadow/InnerShadow JSON shapes [src/jsonUtils/style.ts:L161-L187].
• Per the import graph, the API is centered on a few "hub" files: src/types/index.ts (44 importers) and src/jsonUtils/models.ts (18 importers) define the shared type/JSON vocabulary that almost everything else builds on — these are the best starting points for understanding the API surface, per the architecture signals (grade C, 68/100).

This is a declarative, tree-in/JSON-out API: you build a React tree, call render, and get Sketch documents. It's synchronous and single-purpose (design tooling), not built for runtime error handling or telemetry.

getsentry/sentry-javascript: an instrumentation/observability API

Sentry's packages expose a much broader, multi-runtime API surface aimed at capturing and reporting error/performance data across many JS environments (browser, Node, AWS Lambda, Angular, Astro, etc.). Patterns visible in the chunks:

• Scope/event enrichment functions — e.g., markEventUnhandled(scope, type) in the AWS Lambda package adds exception mechanism metadata via addEventProcessor [packages/aws-serverless/src/utils.ts:L16-L23], and enhanceScopeWithEnvironmentData-style helpers pull Lambda Context fields like getRemainingTimeInMillis() into the Sentry scope [packages/aws-serverless/src/sdk.ts:L80-L90].
• Integration factories — e.g., userTiming in browser-utils uses defineIntegration to register a performance-monitoring integration, pulling from browser Performance APIs [packages/browser-utils/src/performance/userTiming.ts:L1-L12].
• Framework-specific middleware — e.g., the Astro middleware's injectMetaTagsInResponse streams and rewrites HTML responses to inject Sentry meta tags, with explicit error reporting via sendErrorToSentry on stream failures [packages/astro/src/server/middleware.ts:L445-L506].
• Error-normalization utilities — e.g., extractType/extractHttpModuleError functions that coerce framework-specific error shapes (WebAssembly exceptions, Angular's HttpErrorResponse) into a consistent Error/string for reporting [packages/browser/src/eventbuilder.ts:L179-L191], [packages/angular/src/errorhandler.ts:L34-L53].
• A large exported utility surface per-package — browser-utils/src/index.ts re-exports many small focused helpers (addHistoryInstrumentationHandler, addXhrInstrumentationHandler, getBodyString, `htmlTreeA