Refactor build pipeline to esbuild and tsx test runner

[Copilot]

Refactor the build system so production builds use esbuild and tests run directly via tsx without compiling or typechecking test sources.

• Build pipeline
  • Replace tsc build with an esbuild-driven script that glob-resolves TS entry points and outputs ESM to dist/src.
  • Clean dist/src before emitting and copy package.json into dist/ for runtime metadata resolution.
• Test execution
  • Run tests via tsx --test against .test.ts files, bypassing precompilation.
  • Build test Fastify instances directly to avoid fastify-cli parsing under tsx.

{
  "scripts": {
    "build": "node scripts/build.js",
    "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.

[Copilot]

This test helper now creates Fastify() with default server options and then registers the app plugin. That bypasses the exported options from src/app.ts (e.g., pluginTimeout) which Fastify CLI typically uses when starting the app, so tests may run with materially different server configuration than production. Consider passing the relevant server options into the Fastify(...) constructor (and/or merging them with the test config) to keep parity.

[Copilot]

Passed the app’s pluginTimeout into the Fastify constructor so tests use the same server options as production in 35e50c8.

[Copilot]

fastify.close() returns a Promise. Registering teardown as t.after(() => void fastify.close()) drops that Promise, so the test runner may not wait for the server to fully close (potentially causing flakiness or open handles). Prefer making the after-hook async and awaiting fastify.close() so teardown is guaranteed to complete.

Suggested change

	t.after(() => void fastify.close());
	t.after(async () => {
	await fastify.close();
	});

[Copilot]

Teardown now awaits fastify.close() via an async after-hook to avoid open handles (35e50c8).

[Copilot]

src/app.ts imports ../package.json (relative to dist/src/app.js at runtime this becomes dist/package.json). The build script writes to dist/src but does not copy package.json into dist/, so yarn start / the Docker runner stage will fail with a missing JSON module at runtime. Consider copying package.json to dist/package.json as part of the build (or otherwise adjusting how app metadata is loaded so it resolves correctly after build).

[Copilot]

The build script now copies package.json into dist after building so the runtime JSON import resolves (35e50c8).

[Copilot]

The build script doesn't clean dist/src before emitting outputs. Because Fastify autoload loads everything under dist/src/plugins and dist/src/routes, stale JS files from previous builds (e.g., after renames/deletes) can remain and still be autoloaded at runtime. Consider deleting/emptying dist/src at the start of the build to avoid shipping removed routes/plugins.

[Copilot]

The build script now removes dist/src before emitting to avoid stale autoloaded files (35e50c8).

[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.