Fix published package sourcemaps for npm consumers#1769
Conversation
Enable TypeScript inlineSources in the shared package tsconfig so published @workflow packages ship self-contained JavaScript sourcemaps. This fixes Vite and Vitest warnings in downstream repos when sourcemaps point at ../src/*.ts paths that are not published.
🦋 Changeset detectedLatest commit: 6a051d4 The changes in this PR will be included in the next version bump. This PR includes changesets to release 24 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📊 Benchmark Results
workflow with no steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) workflow with 1 step💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) workflow with 10 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) workflow with 25 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) workflow with 50 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) Promise.all with 10 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Express Promise.all with 25 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Express Promise.all with 50 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) Promise.race with 10 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Express Promise.race with 25 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) Promise.race with 50 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) workflow with 10 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) workflow with 25 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) workflow with 50 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) workflow with 10 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Express workflow with 25 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) workflow with 50 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) Stream Benchmarks (includes TTFB metrics)workflow with stream💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) stream pipeline with 5 transform steps (1MB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) 10 parallel streams (1MB each)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) fan-out fan-in 10 streams (1MB each)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) SummaryFastest Framework by WorldWinner determined by most benchmark wins
Fastest World by FrameworkWinner determined by most benchmark wins
Column Definitions
Worlds:
❌ Some benchmark jobs failed:
Check the workflow run for details. |
🧪 E2E Test Results❌ Some tests failed Summary
❌ Failed Tests🌍 Community Worlds (98 failed)mongodb (15 failed):
redis (15 failed):
turso (68 failed):
Details by Category✅ ▲ Vercel Production
✅ 💻 Local Development
✅ 📦 Local Production
✅ 🐘 Local Postgres
✅ 🪟 Windows
❌ 🌍 Community Worlds
✅ 📋 Other
|
TooTallNate
left a comment
There was a problem hiding this comment.
One-line fix in the right place. Flipping inlineSources from false to true in the shared tsconfig makes published sourcemaps self-contained by embedding the original TypeScript source in sourcesContent. This eliminates "points to missing source files" warnings for downstream Vite/Vitest consumers without changing package files entries or expanding tarballs with src/ trees.
Changeset correctly lists all 22 published packages that inherit this config. The tarball size increase from embedded source content is a reasonable trade-off — the maps were already being shipped, they just pointed at files that did not exist in the tarball.
Enable TypeScript inlineSources in the shared package tsconfig so published @workflow packages ship self-contained JavaScript sourcemaps. This fixes Vite and Vitest warnings in downstream repos when sourcemaps point at ../src/*.ts paths that are not published.
Fix published package sourcemaps for npm consumers
Summary
Downstream Vite and Vitest users can currently hit warnings like
Sourcemap for ".../dist/*.js" points to missing source fileswhen@workflow/*packages are inlined during tests. The published packages were shipping sourcemaps that pointed at../src/*.ts, but the matching source files were not present in the npm tarball and the maps did not embedsourcesContent.This left
workflowin an unusable middle state for consumers: sourcemaps were published, but they were not self-contained and the referenced sources were absent.Root cause
The shared package TypeScript base config enabled
sourceMap, but it setinlineSourcestofalse. Packages that publishdist/without publishingsrc/therefore emitted.js.mapfiles that referenced../src/*.tspaths with no embedded source content. Vite eagerly reads those maps, so it warns once per affected file.What changed
inlineSourcesinpackages/tsconfig/base.json.filesentries unchanged. The fix comes from making the published JavaScript sourcemaps self-contained rather than suppressing warnings in consumers or expanding npm tarballs to include everysrc/tree.workflow,@workflow/ai,@workflow/astro,@workflow/builders,@workflow/cli,@workflow/core,@workflow/errors,@workflow/next,@workflow/nitro,@workflow/nuxt,@workflow/rollup,@workflow/serde,@workflow/sveltekit,@workflow/typescript-plugin,@workflow/utils,@workflow/vite,@workflow/vitest,@workflow/world-local,@workflow/world-postgres,@workflow/world-testing, and@workflow/world-vercel.Packages with existing inline JS sourcemaps such as
@workflow/coreandworkflowkeep that shape, but their embedded maps now also carry source content. Packages that ship external.js.mapfiles such as@workflow/builders,@workflow/rollup, and@workflow/vitestnow publish those maps withsourcesContent.This follows the internal
vercel/aiprecedent of shipping usable sourcemaps to npm consumers instead of asking consumers to suppress warnings. Other Vercel OSS packages likeswr,serve, and@vercel/nccavoid this class of problem by not publishing sourcemaps at all. Sinceworkflowalready publishes sourcemaps, embedding source content is the narrowest fix that makes those published maps usable.Validation
Commands run:
pnpm --filter @workflow/core --filter @workflow/builders --filter @workflow/rollup --filter @workflow/vitest buildpnpm --filter @workflow/utils --filter @workflow/errors --filter @workflow/world-local --filter @workflow/world-vercel --filter @workflow/serde buildpnpm pack --pack-destination /tmp/workflow-packinpackages/core,packages/builders,packages/rollup, andpackages/vitest.mapfiles indist/and packaged tarball contents under/tmp/workflow-pack