// Prefer `return` over `return await` in async functions when the await is redundant. Use when writing or reviewing async TypeScript/JavaScript, simplifying control flow, or fixing redundant awaits on returned promises.
| name | no-return-await |
| description | Prefer `return` over `return await` in async functions when the await is redundant. Use when writing or reviewing async TypeScript/JavaScript, simplifying control flow, or fixing redundant awaits on returned promises. |
return over return awaitIn an async function, return await x and return x are equivalent for callers when x is a Promise (or thenable): both return a Promise with the same fulfillment and rejection.
Prefer return x - the extra await adds a microtask and obscures that you are simply forwarding the result.
// Prefer
async function load() {
return fetchData();
}
// Avoid (unless you need await for control flow - see below)
async function load() {
return await fetchData();
}
awaitUse await (including return await) only when you need the async function to suspend on that operation for control flow:
try / catch / finally: To handle or finalize on rejection of the inner promise, you must await it inside try. A bare return innerPromise() does not route that rejection through catch / finally the same way.async function safeLoad() {
try {
// `return await` is correct here so `catch` sees rejections from fetchData()
return await fetchData();
} catch (e) {
return defaultData();
}
}
finally that must run after the inner work settles (same idea - often needs await in the try).If there is no try/catch/finally depending on that promise settling inside the function, do not use return await.
return await expr and nothing in the function uses try/catch/finally around that path for that promise → use return expr.catch or finally must apply to failures of expr → keep await (often return await expr in the try).await + re-wrapping.no-return-await guidance (with the try/catch exception above).Patterns for writing actions (MakeAction/MakeAnonAction), using the Postgres DB (Kysely), and migrating Express routes from MongoDB to Postgres in the Tachi server. Use when adding a new mutation, migrating a Mongo-backed router to Postgres, writing action files, or writing tests for actions or routers.
Aggregates Vitest v8/Istanbul coverage across Tachi workspaces via tachi-coverage-tools (manifest, CLI, optional programmatic API). Use when measuring test coverage, reviewing coverage after changes, adding CI gates, registering a new Vitest package, or when the user mentions coverage reports, coverage-final.json, or just coverage-report.
Guidance on using db-formats/ column lists (SELECT_*) and document mappers (To*Document) instead of selectAll() when writing Postgres-backed endpoints in the Tachi server. Use when writing a new endpoint that reads from a Postgres table, adding a new db-formats file, or when working with Kysely selects that need to return API-compatible (v1-mongodb-like) response shapes.
Prefer staticAssertUnreachable in the default branch of switches that must cover every variant of a union, so exhaustiveness is checked at compile time. Use when writing or reviewing switch on discriminated unions, string literal unions, enums, or any switch meant to be exhaustive in the Tachi TypeScript server.
Migrates server code from MongoDB to Postgres without modifying the legacy Mongo service. Never edits typescript/server/src/services/mongo/ (especially db.ts). Requires removing MONGODB_KILL imports and replacing usage with Postgres (Kysely) in migrated files. Use during Mongo-to-Postgres migration, when migrating routers/actions/utils off
Preserves existing code comments (line, block, JSDoc, region markers) when editing files; does not delete or collapse comments for brevity unless the user asked to remove or update them. Use when editing any source file, refactoring, or applying fixes where comments already exist.