fix(sdk): Derive the published SentryOptions type from its source - #1500
fix(sdk): Derive the published SentryOptions type from its source#1500JPeer264 wants to merge 1 commit into
Conversation
`bundle.ts` restated `SentryOptions` as a hand-written string, so the published `.d.cts`/`.d.mts` could drift from `src/lib/sdk-types.ts` with nothing failing. That is what happened to `headers`: it works at runtime in 0.44.0, but consumers passing it get "does not exist in type 'SentryOptions'". Lift the declaration out of the source file instead, so the two cannot diverge, and guard it with a test. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
| start === -1 ? -1 : sdkTypesSource.indexOf(SENTRY_OPTIONS_END, start); | ||
| if (start === -1 || end === -1) { | ||
| throw new Error( | ||
| `Could not find the \`SentryOptions\` declaration in ${SDK_TYPES_PATH}.` | ||
| ); | ||
| } | ||
| return sdkTypesSource.slice(start, end + SENTRY_OPTIONS_END.length); |
There was a problem hiding this comment.
Bug: The script to extract SentryOptions uses a fragile string search for "\n};" to find the end of the type, which will fail if a nested object is added.
Severity: MEDIUM
Suggested Fix
Instead of relying on fragile string manipulation to parse TypeScript source code, use a more robust method. A better approach would be to use the TypeScript compiler API or a dedicated Abstract Syntax Tree (AST) parser to accurately inspect the SentryOptions type definition and extract its properties. This would make the script resilient to future changes in the type's structure, such as adding nested objects.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.
Location: packages/cli/script/sdk-declarations.ts#L24-L30
Potential issue: The function `extractSentryOptions` in
`packages/cli/script/sdk-declarations.ts` parses the `SentryOptions` type from a source
file using a string-based search. It identifies the end of the type definition by
looking for the first occurrence of `"\n};"`. This logic is fragile because if a
developer adds a nested object type literal to `SentryOptions` in the future, the
extraction will prematurely terminate, resulting in a truncated and incorrect type
definition. The corresponding unit test in `sdk-declarations.test.ts` uses the same
flawed extraction logic, meaning it would not detect this failure, allowing an incorrect
build artifact to be generated silently.
Also affects:
packages/cli/test/script/sdk-declarations.test.ts:26~26
Did we get this right? 👍 / 👎 to inform future reviews.
In #759 I added the headers and missed that there is also a
bundle.tsthat has stringified types in it. With that we 1. add the missingheaderstype and 2. derive the types directly fromsrc/lib/sdk-types.ts- not sure if you're ok with the latter. I could also trim down the PR to just add theheaderstype as string