Summary

Extend the ${file(...)} variable resolver to load TypeScript modules (.ts, .mts, .cts) in addition to the existing JavaScript support (.js, .cjs, .mjs). TypeScript files are compiled on the fly via tsx — the same loader the Framework already uses for serverless.ts — so no separate build step is required.

Before

custom:
  # ✅ worked
  SECRETS: ${file(./scripts/secrets.cjs):getSecrets}

  # ❌ failed: Unsupported file extension
  SECRETS: ${file(./scripts/secrets.ts):getSecrets}

After

Both forms work. From serverless.yml or serverless.ts:

// scripts/secrets.ts
export const getSecrets = async () => ({ apiKey: process.env.API_KEY })

// serverless.ts
custom: {
  SECRETS: '${file(./scripts/secrets.ts):getSecrets}',
}

Details

• Adds .ts / .mts / .cts cases to the file resolver.
• Refactors the JS-module export-shape handler into a shared helper so JS and TS code paths are identical: default-object export, async default-function export, named export, named-export function with #property selector, and injected resolveVariable / resolveConfigurationProperty callbacks all behave the same across JS and TS sources.
• tsx is loaded lazily inside the TS branch so cold-start is unchanged when no TS reference is present.
• Errors are split into two clearer messages: Cannot load TS module "..." for transpile / import failures, and Cannot execute TS module "..." for runtime throws inside the module body.
• Adds tsx as an explicit dependency of @serverlessinc/sf-core (previously resolved transitively).
• Documents both the JavaScript and TypeScript file-reference forms in the file-variables guide — neither was previously documented.

Behavior note

The shared module-shape handler now unwraps the standard CJS↔ESM interop layer (the __esModule: true marker) once before reading exports. Native dynamic import() of a .cjs file already does this collapse implicitly; tsx's tsImport does not, hence the explicit unwrap. As a side effect this also applies to the JS code path:

• Pre-transpiled .cjs / .js files whose module.exports carry an __esModule: true marker (i.e. anything emitted by Babel / TypeScript / esbuild in CJS mode) now return the user's intended default export from ${file(./compiled.js)} and from ${file(./compiled.js):default} — instead of the transpiler wrapper object that was previously returned. This is a correctness fix; the prior wrapper was an interop leak, not an intended contract.
• Files without an __esModule marker, default exports that are not objects (e.g. export default 42), and all hand-authored JS / YAML / JSON / raw-text references are unaffected.

Test plan

• npm run prettier — clean
• npm run lint — clean
• npm run test:unit in packages/sf-core — 386 tests pass (23 pre-existing JS resolver tests unchanged + 11 new TS resolver tests)
• npm run build in packages/sf-core — bundle produces successfully
• Manual end-to-end via sls print against a TS-only repro covering: default-export object, property selector, async named-export function with env-var read, named export from a .ts file using as const
• Manual end-to-end verification of both error branches: TS file with syntax error surfaces Cannot load TS module with the underlying esbuild transform error; TS file whose function throws surfaces Cannot execute TS module with the original error message
• Node 18 compatibility maintained (no new syntax / Node APIs)