Conversation
| })) | ||
|
|
||
| const config: ResourceConfig = { | ||
| order: 1, |
There was a problem hiding this comment.
Lost dependency ordering
Old resources had explicit order (1–19) and dependencies (e.g., prices depend on products). New code sets order: 1 for everything and dependencies: []. This means all resources sync in arbitrary order rather than respecting FK-like dependencies.
|
|
||
| async function fetchSpecForCommit(commitSha: string): Promise<OpenApiSpec> { | ||
| const url = `https://raw.githubusercontent.com/stripe/openapi/${commitSha}/openapi/spec3.json` | ||
| const url = `https://raw.githubusercontent.com/stripe/openapi/${commitSha}/latest/openapi.spec3.sdk.json` |
There was a problem hiding this comment.
spec3.sdk.json vs spec3.json
The spec fetch was changed from openapi/spec3.json to latest/openapi.spec3.sdk.json. The SDK spec includes SDK-specific extensions (x-stripe-* etc.) — is this needed for anything, or would the simpler spec3.json suffice? The SDK spec is significantly larger.
| timestamptz: { type: 'string', format: 'date-time' }, | ||
| } | ||
|
|
||
| export function parsedTableToJsonSchema(table: ParsedResourceTable): Record<string, unknown> { |
There was a problem hiding this comment.
Lost x-source-schema and x-expandable-reference
The old parsedTableToJsonSchema set x-source-schema (from table.sourceSchemaName) and x-expandable-reference on output schemas. This new version doesn't include either. The x-expandable-reference annotation was used downstream — is anything still consuming it?
tonyxiao
left a comment
tonyxiao
left a comment
There was a problem hiding this comment.
i think we should create a list of what we will fix in follow up PRs vs. what we think is good enough for now
Yostra
force-pushed
the
v2-straya
branch
2 times, most recently
from
f64d1da to
32df468
Compare
|
Rebased onto v2 and added a fixup commit ( 1. Rename 2. Remove dead exports from
3. Add missing tarball cleanup in Note: CI failures ( |
tonyxiao
force-pushed
the
v2-straya
branch
8 times, most recently
from
07d4ec6 to
7999109
Compare
1. Package naming convention: every package in the monorepo uses the @stripe/sync-* scope (sync-protocol, sync-engine, sync-source-stripe, etc). Rename to @stripe/sync-openapi for consistency. 2. Remove dead exports from resourceRegistry.ts that were never imported anywhere: StripeObject, CoreSyncObject, SyncObjectName (all just `string` aliases with no narrowing), CORE_SYNC_OBJECTS (redundant re-export of DEFAULT_SYNC_OBJECTS), SYNC_OBJECTS, and RESOURCE_TABLE_NAME_MAP (identity map of table→table). 3. Add missing cleanup line in e2e/connector-loading.test.sh for the openapi tarball — without this the cleanup() trap leaves a stale stripe-sync-openapi-*.tgz in the repo root. Committed-By-Agent: claude
The exports map pointed all conditions at source ./index.ts, which breaks Node after build — index.ts imports ./specParser.js but only .ts source files exist. Node needs the built dist/ files. Use the same pattern as other packages: bun→source for dev, types/import→dist for Node. Drop the unused publishConfig.exports since this package is private. Fixes: bin.js spec exited with code 1: ERR_MODULE_NOT_FOUND Committed-By-Agent: claude
Committed-By-Agent: claude
…nfig types.ts was deleted in an early commit but was still imported by runtimeMappings.ts, specParser.ts, and re-exported via index.ts. Also remove src/openapi from tsconfig exclude so browser.ts barrel (the package's ./browser subpath export) gets compiled to dist. Committed-By-Agent: claude
2 participants
Summary
Use openapi to generate resources inside resourceRegistry.ts
How to test (optional)
To see what resources it finds syncable:
node packages/source-stripe/dist/bin.js discover --config '{"api_key":"$STRIPE_API_KEY"}' | json_pp | grep resource_nameTo sync all resources: