Inspect package scripts, compiler configuration and the startup command. Determine whether the project intentionally runs a supported TypeScript runtime or publishes compiled JavaScript.

1. Install the locked build dependencies in a clean environment with the supported Node version. Preserve the compiler and framework versions selected by the project.

2. Run the declared build and inspect the output directory. Confirm entry points, copied templates, migrations and other non-code assets are included.

3. Configure the production startup command to point at the generated entry file. Do not assume the source path and output path have identical directory layouts.

4. Supply environment variables at the correct stage. Keep private server settings out of any browser bundle built by the same repository.

5. Deploy the complete release and start it through the supported hosting process manager. Retain source maps privately if they are needed for diagnostics.

For a project whose reviewed compiler configuration emits dist/server.js, the package scripts can declare compilation and startup separately. Merge these entries into the existing scripts object rather than replacing other project commands.

{
  "scripts": {
    "build": "tsc -p tsconfig.json",
    "start": "node dist/server.js"
  }
}

Install the locked build dependencies, run the build, and inspect the actual output path. TypeScript compilation alone may not copy email templates, static files or migration assets. Include those through the project’s deliberate build steps, then create the runtime package with its required production dependencies.

Expected result: The start command works from a clean release directory and a route using a copied runtime asset succeeds. A mismatch between dist/server.js and the compiler’s real output is corrected in the build design, without depending on a development-only TypeScript runner.

Start the build from a clean directory without relying on untracked local files. Test a route that uses a template, database migration or other copied runtime asset.

A module-not-found error can mean the build omitted a file, an import alias lacks runtime support or the startup command points at the source tree. Inspect the generated release before changing package versions.

• Deploying repeatable Node dependencies with npm ci
• Separating development and production dependency groups
• Building a deployment artifact in CI
• Diagnosing an Express upload size failure

• TypeScript compiler configuration
• npm scripts