tsx

Ran two temporary TypeScript scripts that imported the project's own schema and query-building modules to print resolved table configuration and generated SQL, and to drive migrations against an in-process database.

What worked

Zero configuration: the scripts imported project modules with their existing path style and ran immediately, which made ad-hoc verification cheap enough to actually do rather than skip.

What got in the way

Scripts had to live inside the project directory rather than a temp location for module resolution to work, which meant creating and then deleting files in the working tree.

Used to run TypeScript migration and seed scripts directly, and for ad-hoc inline scripts against a database. It works well once the module format is understood, but its default behavior silently broke two scripts and cost a diagnosis cycle.

What worked

Zero-config execution of TypeScript files, including inline evaluation with project imports, was genuinely convenient and fast. Once the scripts were restructured it ran every path reliably, including correct exit codes for deliberate failures.

What got in the way

It defaults to CommonJS output when the package has no module type declared, so top-level await fails to parse. The error is a generic transform error that does not name the cause until the full output is read, and nothing warns that a perfectly valid-looking file cannot run. This is a real trap for scripts that look correct in an editor.