Development tools in production dependencies

ts-node and tsconfig-paths are TypeScript compilation tools that have no role in the production server binary. All production scripts (e.g., migration:latest, auditlog-migration:latest) already operate on pre-compiled ./dist/... output and do not invoke ts-node at runtime. Only the -dev migration scripts (e.g., migration:latest-dev) run directly from TypeScript sources and need ts-node.

Including them in dependencies increases the production node_modules install size for every deployment. They should remain in devDependencies — and the eslint import/no-extraneous-dependencies disable comment should be restored in auditlog-knexfile.ts to reflect their dev-only status, exactly as it was before PR #5692.

(Remove ts-node and tsconfig-paths from dependencies and move them back to devDependencies.)

CLI spinner library in production dependencies

ora is a terminal spinner library intended for interactive CLI tooling. It has no role in a production Fastify/Node.js server and will only inflate the production node_modules footprint. It should be placed (or kept) in devDependencies.

Return type mismatch causes non-null assertions throughout callers

getAwsConnectionConfig now returns new AWS.Config({...}) (an AWS SDK v2 config object) instead of a plain { region, credentials } literal. AWS.Config.credentials has the TypeScript type AWS.Credentials | null, so every downstream caller that passes config.credentials to an AWS SDK v3 client (Route53Client, ACMPCAClient, SecretsManagerClient) must suppress the resulting type error with a ! non-null assertion.

The ! assertions hide the real issue: the AWS SDK v2 AWS.Credentials instance is subtly different from the AwsCredentialIdentity ({ accessKeyId, secretAccessKey, sessionToken? }) that v3 clients expect. While v3 will fall back to reading the plain properties and this works in practice, the type mismatch means TypeScript's safety net is disabled for those call-sites.

Returning a plain object keeps the API clean and compatible with both SDK generations:

return {
  region,
  credentials: {
    accessKeyId,
    secretAccessKey,
    sessionToken
  }
};

This avoids the need for ! assertions in route54.ts, aws-pca-certificate-authority-fns.ts, and aws-secrets-manager-sync-fns.ts.

Two-step credential injection is fragile and unnecessary

The SSM client is constructed without credentials and they are applied afterwards via ssm.config.update(config) where config is an AWS.Config instance. AWS.Config.prototype.update() accepts AWS.ConfigurationOptions, not another AWS.Config object, so this relies on duck-typing to copy properties over.

This two-step pattern is harder to reason about and makes it non-obvious that the SSM calls below will authenticate correctly. Passing credentials directly in the constructor — as was done in PR #5692 — is cleaner and more explicit:

const ssm = new AWS.SSM({
  apiVersion: "2014-11-06",
  region: integration.region as string,
  credentials: {
    accessKeyId,
    secretAccessKey,
    sessionToken
  }
});

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}