Decide: do we keep running source .ts directly (Node 24 native strip-types) for local/global use, add a tsc/tsup build step for anything published, or both (native strip for the globally-registered dev copy, compiled dist/ for what actually ships to npm)? And separately: add a tsconfig.json + tsc --noEmit typecheck script regardless, since stripping alone gives zero type safety today. Resolve using the research ticket's findings.
Part of [TypeScript project conventions for delegate-ai-mcp](https://git.arthurerlich.de/haylan/delegate-ai-mcp/issues/1)
Blocked by [How do TS MCP servers conventionally handle build, types, and publishing?](https://git.arthurerlich.de/haylan/delegate-ai-mcp/issues/2)
## Question
Decide: do we keep running source .ts directly (Node 24 native strip-types) for local/global use, add a tsc/tsup build step for anything published, or both (native strip for the globally-registered dev copy, compiled dist/ for what actually ships to npm)? And separately: add a tsconfig.json + tsc --noEmit typecheck script regardless, since stripping alone gives zero type safety today. Resolve using the research ticket's findings.
package.json: add bin (pointing at ./build/index.js), files: ["build"], "build": "tsc && chmod 755 build/index.js".
The globally-registered qwen-delegate server switches from running src/*.ts directly to running the compiled build/index.js; rebuild after each source change.
This makes the earlier erasableSyntaxOnly/native-strip-types sidecar question moot — a real tsc build has no such restriction, so enums/namespaces/parameter-properties/decorators are all available if ever wanted.
Driver: user wants to publish this package to this repo's Gitea package registry via Gitea Actions sooner rather than later, which needs a real build regardless — see the new CI/publish ticket this spun off.
Not yet done: implementation (tsconfig.json/package.json edits, re-registering the MCP server against build/index.js) — that's follow-up work, not part of this decision ticket.
Resolved: adopt the official MCP quickstart's own defaults, build now (not deferred).
- tsconfig.json: target ES2022, module/moduleResolution Node16, strict: true, outDir ./build, rootDir ./src, esModuleInterop, skipLibCheck, forceConsistentCasingInFileNames — verbatim from https://modelcontextprotocol.io/quickstart/server (fetched 2026-09-06).
- package.json: add bin (pointing at ./build/index.js), files: ["build"], "build": "tsc && chmod 755 build/index.js".
- The globally-registered qwen-delegate server switches from running src/*.ts directly to running the compiled build/index.js; rebuild after each source change.
- This makes the earlier erasableSyntaxOnly/native-strip-types sidecar question moot — a real tsc build has no such restriction, so enums/namespaces/parameter-properties/decorators are all available if ever wanted.
- Driver: user wants to publish this package to this repo's Gitea package registry via Gitea Actions sooner rather than later, which needs a real build regardless — see the new CI/publish ticket this spun off.
Not yet done: implementation (tsconfig.json/package.json edits, re-registering the MCP server against build/index.js) — that's follow-up work, not part of this decision ticket.
Reopened and revised: reverting the build-now decision.
Final answer: no build process at all. Keep running src/*.ts directly via Node's native TS type-stripping, exactly as before ticket #3's first resolution. No tsconfig.json, no tsc --noEmit typecheck sidecar, no bin/files/dist, no Gitea Actions build/publish pipeline. package.json stays as-is.
Why: user preference, stated directly — likes writing TypeScript without a build process getting in the way, and doesn't want to maintain a Gitea Actions build/publish setup for this. This supersedes the earlier 'build now, official quickstart defaults' resolution.
Consequence: the erasableSyntaxOnly constraint from the earlier grilling round is real again (Node hard-errors on enums/namespaces-with-code/parameter-properties/decorators when run natively) — accepted, not a concern for this project. Ticket #7 (Gitea Actions build/test/publish) is closed as out of scope since it depended on this decision.
Reopened and revised: reverting the build-now decision.
Final answer: no build process at all. Keep running src/*.ts directly via Node's native TS type-stripping, exactly as before ticket #3's first resolution. No tsconfig.json, no tsc --noEmit typecheck sidecar, no bin/files/dist, no Gitea Actions build/publish pipeline. package.json stays as-is.
Why: user preference, stated directly — likes writing TypeScript without a build process getting in the way, and doesn't want to maintain a Gitea Actions build/publish setup for this. This supersedes the earlier 'build now, official quickstart defaults' resolution.
Consequence: the erasableSyntaxOnly constraint from the earlier grilling round is real again (Node hard-errors on enums/namespaces-with-code/parameter-properties/decorators when run natively) — accepted, not a concern for this project. Ticket #7 (Gitea Actions build/test/publish) is closed as out of scope since it depended on this decision.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Part of TypeScript project conventions for delegate-ai-mcp
Blocked by How do TS MCP servers conventionally handle build, types, and publishing?
Question
Decide: do we keep running source .ts directly (Node 24 native strip-types) for local/global use, add a tsc/tsup build step for anything published, or both (native strip for the globally-registered dev copy, compiled dist/ for what actually ships to npm)? And separately: add a tsconfig.json + tsc --noEmit typecheck script regardless, since stripping alone gives zero type safety today. Resolve using the research ticket's findings.
haylan referenced this issue2026-09-06 14:42:45 +00:00
Resolved: adopt the official MCP quickstart's own defaults, build now (not deferred).
Not yet done: implementation (tsconfig.json/package.json edits, re-registering the MCP server against build/index.js) — that's follow-up work, not part of this decision ticket.
Reopened and revised: reverting the build-now decision.
Final answer: no build process at all. Keep running src/*.ts directly via Node's native TS type-stripping, exactly as before ticket #3's first resolution. No tsconfig.json, no tsc --noEmit typecheck sidecar, no bin/files/dist, no Gitea Actions build/publish pipeline. package.json stays as-is.
Why: user preference, stated directly — likes writing TypeScript without a build process getting in the way, and doesn't want to maintain a Gitea Actions build/publish setup for this. This supersedes the earlier 'build now, official quickstart defaults' resolution.
Consequence: the erasableSyntaxOnly constraint from the earlier grilling round is real again (Node hard-errors on enums/namespaces-with-code/parameter-properties/decorators when run natively) — accepted, not a concern for this project. Ticket #7 (Gitea Actions build/test/publish) is closed as out of scope since it depended on this decision.