ci(framework): assert capability packages ship a runtime entry (no dts-only / half-built)#2432
Merged
Merged
Conversation
…s-only / half-built) Capability packages (services / triggers / plugins) are loaded by the multi-tenant runtime via a DYNAMIC import of their published entry. If a package ships a dts-only / half-built / 0-byte dist — an interrupted build, or a package retired in source but still referenced — the import resolves to nothing and the capability SILENTLY fails to load (e.g. record-change automation never fires, with no user-visible signal). The shared tsup config always emits JS, so this can only happen by accident, and nothing in CI caught it. Extend "Verify build outputs" (which runs right after the full `pnpm build`) with a filesystem assertion that every buildable capability package actually produced its declared `main` runtime entry. Self-maintaining: reads each package's own manifest, skips dirs with no package.json (e.g. a retired service-feed / service-ai leftover) and packages without a build script. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Capability packages under
packages/{services,triggers,plugins}are loaded by the cloud multi-tenant runtime via a dynamic import of their published entry. If one ships a dts-only / half-built / 0-bytedist(an interrupted build, or a package retired in source but still referenced), the import resolves to nothing and that capability silently fails to load — e.g. AI-built record-change automation registers but never fires, with no user-visible signal.The shared
tsupconfig always emits JS (the only toggle,OS_SKIP_DTS, drops declarations, not JS), so a dts-onlydistcan only happen by accident — and nothing in CI caught it. (This came up while debugging a cloud-sidetriggerscapability that wasn't loading; the framework package itself was fine, but there was no guard proving it.)What
Extend the existing Verify build outputs step (runs right after
pnpm build, so no build-ordering ambiguity) with a filesystem assertion that every buildable capability package produced its declaredmainruntime entry.Self-maintaining and false-positive-safe:
main(defaults todist/index.js);package.json(a retiredservice-feed/service-aileftover);scripts.build;-scatches 0-byte half-writes.Validation
trigger-record-change/dist/index.jsis caught and fails the step.ci.ymlparses.🤖 Generated with Claude Code