TypeScript support

Expectations

• I'd like the type benefits of TypeScript without the complexity and hassle of TypeScript not natively running on Node.js. I don't want to think about the TypeScript transpilation whenever I start the server.
• Stack traces that make sense in dev and production out of the box (source maps).
  • Node.js v12.12.0 added --enable-source-maps
• Ideally, the way to run it in production would be the same as dev besides watching for file changes.

What are the standard ways people accomplish this?

• Build before running the server
  • I don't want a bunch of duplicate compiled .js files next to the .ts source. And I don't want to think about a build beforehand when developing.
  • Maybe for production, can build to a build/ directory if the recommendation is to always to use the compiled .js version. tsc && node build/server.js
• https://www.npmjs.com/package/ts-node
  • https://javascript.plainenglish.io/typescript-with-node-and-express-js-why-when-and-how-eb6bc73edd5d
  • Can it be efficient in production?
    • "Compatible with pre-compilation for production"
    • https://github.com/TypeStrong/ts-node/issues/104
    • https://stackoverflow.com/questions/60581617/is-it-a-bad-practise-to-use-ts-node-in-production
• https://deno.land/
  • Does all of the transpilation for us
• https://bun.sh/
  • The new kid on the block
  • Does all of the transpilation for us
  • Lots of chatter about it being so fast and performant (faster than Deno, faster than Node.js)
  • Getting support for vm.Script.runInContext(...) soon (which we need to run the Matrix Public Archive)

Start by reading the expectations and linked references for ts-node, Node.js source maps, Deno, and Bun, then inspect the repository's current server startup and JavaScript setup. Done means the project has a decided TypeScript runtime or build approach, sensible development and production workflows, and useful stack traces without requiring duplicate source files.