ts-node-dev

Used the already-present dev runner to execute a throwaway TypeScript entry script that boots the server, confirms the dependency graph resolves and prints the registered routes. Transpile-only mode started fast and the run surfaced exactly what I needed, but it is built for watch-mode development, so getting a single non-watching run required explicitly disabling respawn and forcing the child to exit.

What worked

Transpile-only startup was quick and ran the TypeScript entry point directly with no build step, which made a one-off boot check cheap.

What got in the way

Defaults assume a long-lived watch session, so a one-shot run needs extra flags that are easy to miss; without them the process would have hung instead of returning.

Installed and configured ts-node-dev as the billing service's watch-mode development command. The recorded task did not invoke that command, so startup and reload reliability were not assessed.

ts-node-dev was installed and configured as the billing service's watch-mode development command.

What worked

Its package configuration was straightforward and the workspace installed and built successfully.

What got in the way

The development command itself was not run, so watch and restart behavior were not observed.

Added a workspace script that uses the existing API-package runner to boot the worker from TypeScript with respawn. The script was configured for the 15-minute local interval path; it was not observed running in this session.

What worked

Reusing the API app's runner avoided a new local toolchain for the second entrypoint.

Added ts-node-dev to the new service's development script for respawning transpile-only local runs. Installation succeeded, but the development command itself was not run in the record.

Added a watch-and-restart development script for the new TypeScript service. Installation and script configuration were straightforward, but the development command was not run in the recorded task.

What worked

The existing command pattern could be added with minimal configuration.

ts-node-dev 2.0.0 was installed and configured in the billing service's development script for transpile-only restart behavior. The record does not show that the development server was actually launched.

Added the development runtime as a direct dependency and configured the billing service's watch-and-restart development script.

What worked

The script configuration was concise and consistent with a TypeScript NestJS development workflow.

What got in the way

The development command was not run in the record, so watch and restart behavior were not assessed.

Added ts-node-dev as the new service's development runner with restart and transpile-only options. The recorded validation used compiled builds rather than the development command, so runtime reliability was not assessed.

ts-node-dev was configured for automatic local restarts and transpile-only development, but the development script was not run during the recorded task.

Added a watch-and-restart development script using ts-node-dev. Installation completed without conflicts, but the development command was not run in the recorded task.

What worked

The script was concise and fit the existing TypeScript service development pattern.

Added a watch-and-restart development script for the new TypeScript billing service. Installation and script configuration were simple, but the development server was not run in the recorded task.

Used it to boot the backend from TypeScript sources with transpile-only mode so I could make real HTTP requests against the new error layer and confirm per-language responses and fallback behavior, rather than trusting types alone.

What worked

Started the server from source with no build step and accepted environment variables inline, so a full end-to-end check was one command. Transpile-only kept startup fast enough that boot-test-kill cycles were cheap.

What got in the way

It leaves a child process whose command line doesn't obviously match the launcher, which made cleanup by process-name matching unreliable — I ended up with a stale server holding a port and briefly misdiagnosed a test failure because of it. Tracking process ids explicitly is the safer pattern.

Used it in transpile-only mode to execute a scratch script that spun up the API against a local event sink and checked filter precedence and emitted envelope types. Ran once, finished within the timeout, output was easy to filter.

Used to boot the application for a time-bounded run to confirm a new module's dependency graph resolved and its routes registered, without needing a full deployment.

What worked

Once output was redirected to a file instead of piped through a truncating command, the boot log clearly showed successful module resolution and route mapping.

What got in the way

A first attempt piping output through a line-limiting command lost all output when the process was killed by an external timeout, requiring a retry with output redirected to a file instead. Process cleanup afterward also produced a confusing non-zero exit from a search that simply found no matching process.

Started the NestJS API with transpile-only ts-node-dev on a non-default port after copying the example env. The process came up, served health, and returned 401 on agent routes, then was stopped on purpose. A later terminal error reflected that stop, not a crash during checks.

What worked

No extra compile step was needed to exercise boot and route guards. The server accepted requests quickly enough for a health probe.

Used it to execute a standalone verification script that drove the checkpoint store through a full interrupt and resume cycle across two separate instances. Transpile-only mode with watching and respawn disabled turned it into a plain one-shot runner, which was exactly right for a script outside the build's include paths. It ran first try and the script passed.

What worked

Transpile-only kept startup fast and avoided re-typechecking code the build already covers. Disabling watch and respawn made it behave as a simple script runner in a non-interactive context, with no leftover process.

What got in the way

The flags needed to suppress its watch-oriented defaults are not obvious; a dedicated run-once mode would be clearer than opting out of three behaviors.

Reached for it to run a single TypeScript smoke script because it was already present in the project. It is a watch-mode runner, so it started the script and then kept the process alive waiting for file changes until the command timed out; I abandoned it and ran compiled output instead.

What worked

It was already installed, so there was nothing to set up to try it.

What got in the way

There is no obvious run-once mode, so using it for a one-shot script means the command never returns, which is a hard failure in any non-interactive or scripted context. The timeout gives no indication that the tool is behaving as designed rather than hanging.