Streamline dev/test with tsx and keep tsc build

[Copilot]

Refactor the workflow to run dev and tests directly via tsx, while keeping production builds on tsc with a clean dist step.

• Build pipeline
  • Keep tsc for production builds and clean dist before emitting to avoid stale autoloaded files.
  • Add a separate typecheck script using tsc --noEmit for app and test type checking.
• Dev & test execution
  • Run tests via tsx --test against .test.ts files without precompiling or copying assets.
  • Run dev with a tsx-driven Fastify starter script.

{
  "scripts": {
    "build": "node scripts/clean-dist.js && tsc",
    "typecheck": "tsc --noEmit && tsc -p test/tsconfig.json --noEmit",
    "dev": "node scripts/clean-dist.js && FASTIFY_AUTOLOAD_TYPESCRIPT=1 tsx watch scripts/dev.ts",
    "test": "FASTIFY_AUTOLOAD_TYPESCRIPT=1 tsx --test --experimental-test-coverage test/**/*.test.ts"
  }
}

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[Copilot]

Pull request overview

This PR refactors the project’s build and test workflow by switching production builds from tsc to an esbuild-driven script, and switching test execution to run TypeScript tests directly via tsx --test (no precompiled test output).

Changes:

• Add an esbuild-based build script (scripts/build.js) to emit ESM JS into dist/src.
• Update test helper to construct Fastify instances directly (avoiding fastify-cli/helper under tsx).
• Update package.json scripts/deps and lockfile to include esbuild and tsx.

Reviewed changes

Copilot reviewed 3 out of 4 changed files in this pull request and generated 4 comments.

File	Description
yarn.lock	Adds lock entries for esbuild, tsx, and transitive deps.
test/helper.ts	Replaces fastify-cli test helper usage with direct Fastify instance setup.
scripts/build.js	New esbuild build script that compiles src/**/*.ts into dist/src.
package.json	Updates build/test scripts and adds esbuild + tsx dev dependencies.

Comments suppressed due to low confidence (1)

package.json:18

• yarn dev still runs tsc -w while build is now esbuild-based. Since dev:start serves from dist/src/app.js, changes during development will be emitted by tsc (not esbuild), which can lead to runtime differences vs the production build pipeline this PR introduces. Consider updating watch/dev to use an esbuild watch mode (or otherwise ensure dev and prod builds use the same compiler/output semantics).

    "build": "node scripts/build.js",
    "build:test": "yarn build && node scripts/copy-test-assets.js",
    "watch": "tsc -w",
    "start": "fastify start -l info dist/src/app.js --options",
    "dev": "yarn run build && concurrently -k -p '[{name}]' -n TypeScript,App -c yellow.bold,cyan.bold yarn:watch yarn:dev:start",
    "dev:start": "fastify start --ignore-watch='.ts$' -w -l debug -P dist/src/app.js --options",

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[FlandiaYingman]

@copilot apply changes based on the comments in this thread. In addition, remove all unused things (scripts, files, etc.)

[Copilot]

@copilot apply changes based on the comments in this thread. In addition, remove all unused things (scripts, files, etc....

Applied the review feedback and removed the unused build:test script and copy-test-assets helper in 35e50c8.

[FlandiaYingman]

@polyipseity I'm thinking to run dev and tests directly (via tsx or something else); type checking them should be in a separate script. Benefits include quicker dev and tests, and we don't have to copy the assets everywhere.

I'm still not sure if we should touch build (i.e., change it to esbuild). It seems that there is no benefit of doing so. WDYT?

[polyipseity]

@polyipseity I'm thinking to run dev and tests directly (via tsx or something else); type checking them should be in a separate script. Benefits include quicker dev and tests, and we don't have to copy the assets everywhere.

I'm still not sure if we should touch build (i.e., change it to esbuild). It seems that there is no benefit of doing so. WDYT?

Yeah, the tsx approach is good. (Also removes the need to copy assets). Use tsc --noEmit to type check without producing files to dist.

For esbuild, we don't benefit from it because bundling is incompatible with autoload. esbuild is probably faster than tsc but it skips type checking. Using tsc like the old approach keeps type checking, and is also simpler (no separate build system).

If we keep using tsc for build, one thing that could be improved is that in the script for build (and also dev), we should empty the dist directory first to ensure no stale files affecting autoload.

The remaining changes are good!

[FlandiaYingman]

we should empty the dist directory first

Yes that's always been an issue that annoys me when it's the case for dev. But IDK if that matters a lot because we only build in the docker image

[polyipseity]

we should empty the dist directory first

Yes that's always been an issue that annoys me when it's the case for dev. But IDK if that matters a lot because we only build in the docker image

It's still good to set it for consistency (and in case you run build locally for some reason).

[FlandiaYingman]

@copilot

Based on the following discussion of this PR, design and implement the features and fixes.

1. Streamline dev/test with tsx and keep tsc build #59 (comment)
2. Streamline dev/test with tsx and keep tsc build #59 (review)
3. Streamline dev/test with tsx and keep tsc build #59 (comment)
4. Streamline dev/test with tsx and keep tsc build #59 (comment)

[Copilot]

@copilot

Based on the following discussion of this PR, design and implement the features and fixes.
...

Implemented the requested changes (tsx dev/test, separate typecheck, tsc build with dist cleanup, removed esbuild tooling) in 83136ac.