-
Notifications
You must be signed in to change notification settings - Fork 38
Open
Description
Problem
Every time a new request, command, or notification is added to the Tasks IPC layer, it must be manually defined in three places:
packages/shared/src/tasks/api.ts— canonicaldefineRequest/defineCommand/defineNotification+TasksApiobjectpackages/tasks/src/hooks/useTasksApi.ts— webview-side wrapper that re-lists every entry as a convenience methodsrc/webviews/tasks/tasksPanel.ts— extension-siderequestHandlers/commandHandlersmaps that re-list every entry by method name
Nothing enforces that these three stay in sync. Forgetting to wire up a new method in one of them is a silent bug — the TypeScript compiler won't catch it.
Desired outcome
- A single source of truth (
TasksApi) should drive the handler/hook shape so the compiler errors when a method is missing. - Ideally,
useTasksApiand theTasksPanelhandler maps could be partially or fully generated/inferred from theTasksApidefinition (e.g. mapped types, helper that iterates overTasksApientries, or codegen). - Adding a new request/command/notification should require touching as few files as possible — ideally just the definition and the implementation.
Ideas
- Use mapped types over
typeof TasksApito derive the required handler signatures, makingrequestHandlers/commandHandlerstype-incomplete if a handler is missing. - Generate
useTasksApifromTasksApientries automatically (the hook is already a thinrequest()/command()pass-through). - Explore a registry pattern or codegen script that reads the
TasksApiobject and emits boilerplate.
Created on behalf of @EhabY
Reactions are currently unavailable