fix(build): co-copy rollup content-hashed sibling .d.ts chunks (#1500) - #1503
fix(build): co-copy rollup content-hashed sibling .d.ts chunks (#1500)#1503iroiro147 wants to merge 1 commit into
Conversation
…l#1500) Some upstream packages emit rollup content-hashed sibling chunks (e.g. chat's messages-BSoJG691.d.ts, @chat-adapter/twilio's types-WYjTBVDi.d.ts) that their public declarations reference via relative import. Because createDeclarationCopier only co-copied explicit 'files' plus whatever discoverExtraFiles matched (chat listed 'jsx-runtime-*' specifically, twilio listed only its 5 entry points), these chunks were silently left behind. The published package's declarations then resolved those imports to 'any' under skipLibCheck: true, silently degrading ~120 exported types across the Chat SDK surface and Twilio's TwilioWebhookUrl / TwilioVerifiedRequest. With skipLibCheck: false the hole surfaced as TS2307: Cannot find module './messages-BSoJG691.js'. Fix it root-causally: after the existing files/co-copy step, scan each written declaration for relative import specifiers (from './x.js', from '../y.d.ts', export * from './z.js', side-effect import './w.js'), resolve them against the upstream dist/, and co-copy any matches — recursively, with cycle protection. This subsumes discoverExtraFiles for the sibling-chunk class of problem; chat.mjs's jsx-runtime regex remains in place as belt-and-braces but the new helper catches its matches too. Verified locally: pnpm build:compiled now emits .generated/compiled/chat/messages-BSoJG691.d.ts and .generated/compiled/@chat-adapter/twilio/types-WYjTBVDi.d.ts, both content-matching the upstream packages the reporter linked. Added a regression scenario test that asserts both chunk files exist on disk and that the chat/twilio entry points still reference their hashed siblings (i.e. we copied the target alongside rather than stripping the import). Refs vercel#1500 Signed-off-by: iroiro147 <sarthak.singh@juspay.in>
|
@iroiro147 is attempting to deploy a commit to the Vercel Team on Vercel. A member of the Team first needs to authorize it. |
|
FYI on the current CI failures: the Failing files (all in unrelated subsystems, all on I verified by running This PR itself only touches I'll keep the branch freshly synced with |
Summary
Fixes #1500 — published
evepackage was silently missing two rollup content-hashed sibling declaration chunks that its own vendored.d.tsfiles import:chat'smessages-BSoJG691.d.ts(referenced fromchat/index.d.ts)@chat-adapter/twilio'stypes-WYjTBVDi.d.ts(referenced from@chat-adapter/twilio/webhook.d.ts)The type hole degraded ~120 exported names across the Chat SDK surface (
Adapter,Chat,ChatInstance,Message,Thread,Attachment,FileUpload,PostableCard,PostableMessage,StateAdapter,UserInfo, …) plusTwilioWebhookUrl/TwilioVerifiedRequesttoanyunder the defaultskipLibCheck: true, and surfaced asTS2307: Cannot find module './messages-BSoJG691.js'underskipLibCheck: false.Root cause
createDeclarationCopier(packages/eve/scripts/vendor-compiled/_shared.mjs) had two ways to bring upstream.d.tsfiles into the vendored output:files:— hardcoded list (twilio listed only its 5 entry points).discoverExtraFiles— a per-package filename matcher (chat listed onlyjsx-runtime-<hash>.d.ts).Meanwhile
collectExternalDeclarationImportsdeliberately skips relative specifiers (./…), so nothing in the pipeline noticed when a vendored declaration referenced a sibling content-hashed chunk. The result: both hashed chunks were left behind.Fix
Add a transitive relative-import co-pass to
createDeclarationCopier: after the existing files/extra-files copies, scan each written declaration for relative import specifiers (from './x.js',from '../y.d.ts',export * from './z.js', side-effectimport './w.js'), resolve them against the upstream package'sdist/, and co-copy any matches — recursively, with cycle protection.This subsumes
discoverExtraFilesfor the sibling-chunk class of problem: chat.mjs'sjsx-runtime-regex remains in place as belt-and-braces but the new helper catches its matches too. The helper is generic across all vendored packages, so future content-hashed chunks in any vendored dependency are picked up automatically — no more per-package regexes.Verification
Locally (
pnpm build:compiled):Both chunk filenames and contents match the upstream packages the reporter linked:
chat@4.34.0→dist/messages-BSoJG691.d.ts✓@chat-adapter/twilio@4.35.0→dist/types-WYjTBVDi.d.ts✓Test suite:
pnpm exec vitest run test/scenarios/compiled-vendor-assets.scenario.test.ts— 8/8 pass (7 existing + 1 new regression test).Type check on the changed script + test: clean (pre-existing baseline of 124 errors in 8 unrelated files unchanged).
Regression test
Added
(eve#1500) co-copies content-hashed sibling declaration chunks referenced by vendored entriestocompiled-vendor-assets.scenario.test.ts:chat/index.d.tsstill references./messages-BSoJG691andwebhook.d.tsstill references./types-WYjTBVDi(i.e. we copied the target alongside, not stripped the import).Why this shape and not the cheap fix
Alternative considered: just extend the regexes to include
messages-*.d.tsandtypes-*.d.ts. Rejected because (a) rollup hashes change per version bump and would silently re-break on the next vendored dependency upgrade, and (b) the reactive-regex pattern would have caught this bug only for the two currently-known chunks. The transitive closure approach is immune to hash churn and automatically picks up new chunks in any vendored package.