Platform source has TypeScript errors in unused-feature files (static-site.ts, vpc.ts) — blocks strict tsc users

[DivMode]

Summary

SST 4.14.3 platform source has two TypeScript errors that surface for any user typechecking infra code with strict tsc --noEmit. The bugs are in features the user doesn't necessarily use (sst.cloudflare.StaticSite, sst.aws.Vpc) but tsc compiles them transitively via namespace re-exports, so users hit them regardless.

This is related to but distinct from #5890 — that issue is about the broader architecture (platform .ts source vs .d.ts); this issue is about two specific, fixable bugs.

Repro

# Any SST 4.14.3 project with @pulumi/cloudflare 6.16+ and @pulumi/aws 7.x
npx tsc --noEmit --project tsconfig.infra.json

Errors

.sst/platform/src/components/cloudflare/static-site.ts(404,22): error TS2488:
  Type 'UnwrappedArray<Input<WorkersScriptBinding>> | undefined' must have a
  '[Symbol.iterator]()' method that returns an iterator.

.sst/platform/src/components/aws/vpc.ts(985,19): error TS2353:
  Object literal may only specify known properties, and 'vpc' does not exist in type 'EipArgs'.

.sst/platform/src/components/aws/vpc-v1.ts(247,17): error TS2353:
  Object literal may only specify known properties, and 'vpc' does not exist in type 'EipArgs'.

Root cause

static-site.ts line ~404:

workerArgs.bindings = output(workerArgs.bindings ?? []).apply(
  (bindings) => [
    ...bindings,                       // ← `bindings` is `T[] | undefined` here
    { type: "kv_namespace", ... },
  ],
);

bindings after the output().apply() is UnwrappedArray<Input<WorkersScriptBinding>> | undefined. The spread ...bindings fails the iterability check when it's undefined. Fix: ...(bindings ?? []).

aws/vpc.ts line ~985 and aws/vpc-v1.ts line ~247:

new ec2.Eip(..., { vpc: true }, ...);

@pulumi/aws v7 deprecated vpc in favor of domain: "vpc". Looking at the dev branch this is already fixed there, just hasn't been released past 4.14.3 yet.

Suggested fix

1. static-site.ts: replace ...bindings, with ...(bindings ?? []), (1 line)
2. aws/vpc.ts + aws/vpc-v1.ts: replace vpc: true, with domain: "vpc", (already done on dev branch)
3. Cut a 4.14.4 release with both fixes

Workaround in the meantime

We use a sed-based patch script in our build pipeline. Idempotent, grep-gated. Documented as a temporary workaround pointing back to this issue.

# cloudflare/static-site.ts
sed -i '' 's|^                  \.\.\.bindings,$|                  ...(bindings ?? []),|' \
  .sst/platform/src/components/cloudflare/static-site.ts

# aws/vpc.ts + aws/vpc-v1.ts
sed -i '' 's|vpc: true,|domain: "vpc",|' .sst/platform/src/components/aws/vpc.ts
sed -i '' 's|vpc: true,|domain: "vpc",|' .sst/platform/src/components/aws/vpc-v1.ts

Why this matters

These errors don't affect sst dev / sst deploy (those use esbuild, which is lenient on types). They only bite users who run strict tsc against their infra code for fast-feedback typechecking — a common pattern. Without a fix, every such user either patches platform source post-install or gives up strict typechecking.

Once #5890's larger fix lands (ship .d.ts or move SST to node_modules), this becomes moot. Until then, three one-line source fixes would unblock the strict-tsc cohort.

[DivMode]

Update — additional finding (2026-05-22 cleanup session)

After a fresh bunx sst install against SST 4.14.3 today, two things to update on this issue:

1. aws/vpc.ts + aws/vpc-v1.ts — already fixed in 4.14.3 source

Current state of the 4.14.3 bundled source:

.sst/platform/src/components/aws/vpc.ts:1030:    domain: "vpc",
.sst/platform/src/components/aws/vpc-v1.ts:247:  domain: "vpc",

The sed patch for those two files matches zero lines today — they ship with domain: "vpc" baked in. Suggest dropping that half of this issue; only the static-site.ts portion is still actionable for the original report.

2. New finding: cloudflare/helpers/compatibility.ts narrow types

Same fresh install surfaced two NEW TS2345 errors that aren't in the original report:

.sst/platform/src/components/cloudflare/ssr-site.ts(145,37): error TS2345:
  Argument of type 'WorkerArgs' is not assignable to parameter of type 'CompatibilityArgs'.

.sst/platform/src/components/cloudflare/worker.ts(392,50): error TS2345:
  Argument of type 'WorkerArgs' is not assignable to parameter of type 'CompatibilityArgs'.

Root cause: cloudflare/helpers/compatibility.ts lines 14-15:

type CompatibilityArgs = {
  // ...
  transform?: {
    worker?:
      | {
          compatibilityDate?: Input<string>;            // ← too narrow
          compatibilityFlags?: Input<Input<string>[]>;  // ← too narrow
        }
      | ((...args: any[]) => undefined);
  };
};

But @pulumi/cloudflare@6.16.0's WorkersScriptArgs declares both as Input<X | undefined>:

compatibilityDate?: pulumi.Input<string | undefined>;
compatibilityFlags?: pulumi.Input<pulumi.Input<string>[] | undefined>;

When SST passes args (typed WorkerArgs containing transform.worker: Transform<WorkersScriptArgs>) into normalizeCompatibility(args), the type collision fires from two callsites: worker.ts:392 and ssr-site.ts:145.

Suggested fix

Widen CompatibilityArgs to match the provider:

   transform?: {
     worker?:
       | {
-          compatibilityDate?: Input<string>;
-          compatibilityFlags?: Input<Input<string>[]>;
+          compatibilityDate?: Input<string | undefined>;
+          compatibilityFlags?: Input<Input<string>[] | undefined>;
         }
       | ((...args: any[]) => undefined);
   };

Updated workaround sed (replaces the vpc.ts sed lines that are now no-ops)

COMPAT=".sst/platform/src/components/cloudflare/helpers/compatibility.ts"
if grep -q 'compatibilityDate?: Input<string>;' "$COMPAT"; then
  sed -i '' 's#compatibilityDate?: Input<string>;#compatibilityDate?: Input<string | undefined>;#' "$COMPAT"
  sed -i '' 's#compatibilityFlags?: Input<Input<string>\[\]>;#compatibilityFlags?: Input<Input<string>[] | undefined>;#' "$COMPAT"
fi

# Still needed (unchanged from original report):
STATIC_SITE=".sst/platform/src/components/cloudflare/static-site.ts"
if grep -q '^                  \.\.\.bindings,$' "$STATIC_SITE"; then
  sed -i '' 's|^                  \.\.\.bindings,$|                  ...(bindings ?? []),|' "$STATIC_SITE"
fi

So the actionable remaining set in this issue is two files, not three: static-site.ts (original) + helpers/compatibility.ts (new). Cutting a 4.14.4 with both fixes would unblock our strict-tsc pipeline (and presumably every other monorepo doing the same).