Published SDK/core packages ship their test files, and 14 of them require vitest which isn't a dependency #4825

What

The published @trigger.dev/sdk and @trigger.dev/core tarballs include their compiled test files, and 14 of the SDK's shipped tests require("vitest"), which is not a dependency of either package. So there are modules inside the published package that cannot resolve.

Verified on @trigger.dev/sdk@4.5.13 / @trigger.dev/core

@trigger.dev/sdk    28 .test.js + 28 .test.d.ts (84 test artifacts incl. maps)
@trigger.dev/core   72 .test.js + 72 .test.d.ts (216 test artifacts incl. maps)

> require("@trigger.dev/sdk/dist/commonjs/v3/auth.test.js")
MODULE_NOT_FOUND: Cannot find module 'vitest'

> Object.keys(require("@trigger.dev/sdk/package.json").dependencies)
[ '@opentelemetry/api', '@opentelemetry/semantic-conventions', '@trigger.dev/core', 'uncrypto' ]
// vitest is not in dependencies or peerDependencies

For size, the SDK's test artifacts are 388 KB across 56 files — about 6.6% of the 5.71 MB package.

Why it matters

Mostly it's dead weight that every install pays for. The unresolvable require is the part that can actually bite: tooling that walks or bundles every file in a package (some bundler configs, license/dependency scanners, require-graph analysis) will hit a module that can't resolve, and the failure points at vitest rather than at anything the user did.

Related, dist/commonjs/v3/schedules/index.types.test.js references an undeclared runtimeWindow:

cron: { pattern: "*/5 * * * *", window: runtimeWindow },

That's harmless as long as the file never executes — it looks like a declare const in the TS source that compiled away — but it's another artifact that only exists because type-tests are being emitted and shipped.

Cause

package.json has "files": ["dist", "docs", "skills"], so everything under dist is published, and the test files are compiled into dist alongside the rest.

Possible fix

Either exclude tests at the tsconfig level so they never reach dist, or keep emitting them and filter at publish time — e.g. a negated pattern in files, or moving type-tests out of the compiled source tree. I haven't opened a PR since the right approach depends on whether the emitted .test.d.ts files are relied on internally, but happy to put one together if you'd like a particular direction.

(Found by running eslint --rule no-undef over the published dist — same sweep that surfaced the envvars.update() bug in #4264.)