@checkstack/frontend-api 0.4.2 → 0.5.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -1,5 +1,165 @@
1
1
  # @checkstack/frontend-api
2
2
 
3
+ ## 0.5.1
4
+
5
+ ### Patch Changes
6
+
7
+ - Updated dependencies [9016526]
8
+ - @checkstack/common@0.10.0
9
+ - @checkstack/signal-common@0.2.3
10
+
11
+ ## 0.5.0
12
+
13
+ ### Minor Changes
14
+
15
+ - aa89bc5: Replace the bespoke `registerInfrastructureTab()` registry with a standard
16
+ slot-extension contract (`InfrastructureTabsSlot` from
17
+ `@checkstack/infrastructure-common`). Plugins now contribute infrastructure
18
+ tabs via `createSlotExtension`, depending only on the slot owner.
19
+
20
+ The slot system in `@checkstack/frontend-api` gains a second type parameter
21
+ on `createSlot<TContext, TMetadata>` so extensions can declare typed static
22
+ metadata at registration time (label, icon, access rules, ordering for the
23
+ infrastructure tab bar). A new `useSlotExtensions(slot)` hook returns typed
24
+ extensions and subscribes to plugin lifecycle changes.
25
+
26
+ Each tab body now stacks a **Runtime** sub-section (live state, read-only)
27
+ on top of a **Configuration** sub-section (settings, gated by `canUpdate`).
28
+
29
+ **Queue runtime panel.** Surfaces aggregated counts (pending / processing /
30
+ completed / failed) plus three sub-tabs of recent jobs: **Active**, **Recent
31
+ failed** (with the failure message), and **Recent completed** (with
32
+ duration). Job payloads are deliberately not surfaced — they may carry
33
+ secrets and need a separate manage-access gate to be shown.
34
+
35
+ To support this, `Queue<T>` gains a required `listJobs(opts)` method
36
+ returning `JobSummary[]` (no payloads), and `QueueStats` gains a
37
+ `scope: "instance" | "cluster"` field. The in-memory queue keeps rolling
38
+ ring buffers (200 entries) for completed/failed history and tracks active
39
+ jobs by id; BullMQ uses native `getJobs`. `QueueManager.listJobs` aggregates
40
+ across queues and sorts (most-recent-first for terminal states, FIFO for
41
+ active/waiting/delayed).
42
+
43
+ **Cache runtime panel.** Lists the top N entries by size (or by recency) so
44
+ operators can debug a cache filling up. Values are deliberately omitted —
45
+ PII / secret risk. Backends opt in via an optional `listEntries?` method on
46
+ `CacheProvider`; non-supporting backends return `{ supported: false }` and
47
+ the UI renders a "not supported by this backend" hint. The in-memory cache
48
+ implements it using its existing per-entry byte tracking.
49
+
50
+ `CacheStats` also gains `scope: "instance" | "cluster"`.
51
+
52
+ **Multi-instance scope warning.** A new `<InstanceScopeBanner>` component in
53
+ `@checkstack/ui` renders a yellow banner above any runtime panel whose
54
+ backend reports `scope: "instance"` — i.e. in-memory queue or cache running
55
+ in a horizontally scaled deployment. The banner explains the metrics are
56
+ local to the responding replica and recommends switching to a clustered
57
+ backend (Redis-backed queue / cache) for cluster-wide visibility.
58
+
59
+ **Bug fix — stable cache provider proxy.** `CacheManagerImpl.getProvider()`
60
+ now returns a single stable proxy that delegates to whatever provider is
61
+ currently active. Previously, consumers of `createCachedScope` (and any
62
+ direct `cacheManager.getProvider()` caller) captured the active provider
63
+ reference at plugin-init time. After any `setActiveBackend` call — including
64
+ saving the same memory config in the new Cache tab, which reconstructs the
65
+ in-memory cache — those scopes wrote to an orphaned old provider while the
66
+ runtime panel read stats from the new (empty) one, making the runtime panel
67
+ appear to report 0 keys. With the proxy, all consumers share a single stable
68
+ identity and writes always land in the active provider.
69
+
70
+ **Bytes tracking on the in-memory cache.** `InMemoryCache.getStats().sizeBytes`
71
+ now returns a running approximation (UTF-8 bytes of the key plus
72
+ `v8.serialize(value).byteLength`, with a JSON fallback) that's kept in sync
73
+ across all eviction paths. Treat the number as a sanity gauge; it doesn't
74
+ include `Map` per-entry overhead.
75
+
76
+ **Pagination.** Both `Queue<T>.listJobs` and `CacheProvider.listEntries?`
77
+ are offset-paginated. Inputs gain an `offset: number`; outputs change to
78
+ `{ items, total: number | null, hasMore: boolean }`. `total` is nullable
79
+ so backends that can't compute it cheaply still paginate via `hasMore`.
80
+ The UI uses the existing `<Pagination>` component with a 25-row default
81
+ page size. `QueueManager.listJobs` aggregates by over-fetching
82
+ `[0, offset+limit)` per queue, merge-sorting, then slicing the window —
83
+ optimal for the single-queue case, acceptable for the multi-queue case
84
+ within the UI's reasonable page-depth bounds. BullMQ uses native offset
85
+ ranges via `getJobs(types, start, end)` plus `getJobCounts` for `total`.
86
+
87
+ **Pending tab.** The Queue runtime panel exposes a virtual `"pending"`
88
+ state (waiting ∪ delayed, FIFO). It's now the default sub-tab, since
89
+ "what's queued up?" is the most common question. Per-row state is shown
90
+ when viewing the combined list.
91
+
92
+ **Recurring schedules visible under Pending.** Cron- and interval-based
93
+ recurring jobs (e.g. healthchecks) are surfaced under Pending/Delayed
94
+ between fires, with a `nextRunAt` countdown column and a "(recurring)"
95
+ label. `JobSummary` gains optional `nextRunAt: Date` and `recurring:
96
+ boolean` fields. The in-memory queue synthesises these rows from its
97
+ `recurringJobs` registry; BullMQ already materialises the next fire of
98
+ each scheduler as a delayed job and we now surface its trigger time and
99
+ the `repeatJobKey`-derived `recurring` flag.
100
+
101
+ **Bug fix — drop hook emits with no listeners.** `EventBus.emit` no
102
+ longer enqueues a job when zero listeners (distributed or instance-local)
103
+ are registered for the hook. Previously, hooks like
104
+ `core.plugin.initialized` — emitted on every plugin init but subscribed
105
+ to by nothing in the core repo — accumulated one waiting job per emit
106
+ forever. The in-memory queue's `processNext` short-circuits when there
107
+ are zero consumer groups, so its post-loop cleanup never ran for these
108
+ orphaned jobs. The fix drops the emit at the source and logs a debug
109
+ line. Note: in distributed deployments using a Redis-backed queue, this
110
+ means a subscriber on another replica won't receive an event if no
111
+ replica that emits it has a local listener. Plugins needing cross-process
112
+ delivery must register their listener on every replica that should
113
+ receive the hook.
114
+
115
+ **Breaking notes (treated as minor under beta semantics)**:
116
+
117
+ - `@checkstack/infrastructure-common` removes `registerInfrastructureTab`
118
+ and `getInfrastructureTabs`; former callers must register an extension
119
+ into `InfrastructureTabsSlot`.
120
+ - `@checkstack/queue-api`'s `Queue<T>` interface requires the new
121
+ `listJobs(opts)` method returning `ListJobsResult` (paginated). Both
122
+ bundled queue backends (memory, BullMQ) are updated; out-of-tree
123
+ implementations will need to add it.
124
+ - `QueueStats` and `CacheStats` add a required `scope` field.
125
+ - `CacheProvider.listEntries?` (when implemented) now returns
126
+ `ListEntriesResult` instead of `CacheEntrySummary[]`.
127
+ - `JobState` adds a `"pending"` variant.
128
+
129
+ - 950d6ec: Fix mobile UserMenu items rendering at zero height, group menu items by
130
+ section, and unstack cramped card headers on small viewports.
131
+
132
+ - **UserMenu mobile bug**: On mobile, the user-menu Sheet rendered every
133
+ menu item as a grid row, which combined with `flex-shrink: 1` on each
134
+ item collapsed the buttons whose internal layout uses `display: flex`
135
+ (the items registered with `useNavigate` rather than `<Link>`) to zero
136
+ content height. Switched the mobile container to a flex column with
137
+ `[&>*]:shrink-0` and added `min-h-0` so the sheet scrolls correctly
138
+ when the list overflows.
139
+
140
+ - **UserMenu grouping**: Slot extensions now accept an optional `group`
141
+ field. The user menu buckets `UserMenuItemsSlot` extensions by `group`
142
+ and renders each group under a labeled header (`Workspace`,
143
+ `Reliability`, `Configuration`, `Documentation`, `Account`). Existing
144
+ core plugins are tagged with the appropriate group; third-party plugins
145
+ can pick any of these or supply their own label. Untagged extensions
146
+ render last with no header. `UserMenuItemsBottomSlot` is unaffected.
147
+
148
+ - **Card header responsiveness**: `CardHeaderRow` (the primitive shared by
149
+ Incident, Maintenance, Auth, Catalog, GitOps and other config cards) now
150
+ stacks vertically on narrow viewports and only switches to a single row
151
+ at the `sm` breakpoint, so titles and adjacent filter controls (e.g.
152
+ status `Select`, "Show resolved" checkbox) no longer cram together on
153
+ mobile. Refactored the Incident and Maintenance config pages to use the
154
+ primitive instead of a hand-rolled `flex items-center justify-between`
155
+ row, and made their `Select` triggers full-width on mobile.
156
+
157
+ ### Patch Changes
158
+
159
+ - Updated dependencies [42abfff]
160
+ - @checkstack/common@0.9.0
161
+ - @checkstack/signal-common@0.2.2
162
+
3
163
  ## 0.4.2
4
164
 
5
165
  ### Patch Changes
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@checkstack/frontend-api",
3
- "version": "0.4.2",
3
+ "version": "0.5.1",
4
4
  "license": "Elastic-2.0",
5
5
  "type": "module",
6
6
  "main": "./src/index.ts",
@@ -13,8 +13,8 @@
13
13
  "react": "^18.0.0"
14
14
  },
15
15
  "dependencies": {
16
- "@checkstack/common": "0.7.0",
17
- "@checkstack/signal-common": "0.2.0",
16
+ "@checkstack/common": "0.9.0",
17
+ "@checkstack/signal-common": "0.2.2",
18
18
  "@orpc/client": "^1.13.14",
19
19
  "@orpc/contract": "^1.13.14",
20
20
  "@orpc/react-query": "1.13.4",
@@ -25,8 +25,8 @@
25
25
  "@types/bun": "^1.3.5",
26
26
  "@types/react": "^18.0.0",
27
27
  "typescript": "^5.0.0",
28
- "@checkstack/tsconfig": "0.0.6",
29
- "@checkstack/scripts": "0.1.2"
28
+ "@checkstack/tsconfig": "0.0.7",
29
+ "@checkstack/scripts": "0.3.1"
30
30
  },
31
31
  "checkstack": {
32
32
  "type": "tooling"
@@ -7,7 +7,7 @@ import type { SlotDefinition } from "../slots";
7
7
  * Extracts the context type from the slot definition itself,
8
8
  * ensuring the context matches what the slot expects.
9
9
  */
10
- type ExtensionSlotProps<TSlot extends SlotDefinition<unknown>> =
10
+ type ExtensionSlotProps<TSlot extends SlotDefinition<unknown, unknown>> =
11
11
  SlotContext<TSlot> extends undefined
12
12
  ? { slot: TSlot; context?: undefined }
13
13
  : { slot: TSlot; context: SlotContext<TSlot> };
@@ -24,7 +24,7 @@ type ExtensionSlotProps<TSlot extends SlotDefinition<unknown>> =
24
24
  * <ExtensionSlot slot={NavbarRightSlot} />
25
25
  * ```
26
26
  */
27
- export function ExtensionSlot<TSlot extends SlotDefinition<unknown>>({
27
+ export function ExtensionSlot<TSlot extends SlotDefinition<unknown, unknown>>({
28
28
  slot,
29
29
  context,
30
30
  }: ExtensionSlotProps<TSlot>) {
package/src/index.ts CHANGED
@@ -4,6 +4,7 @@ export * from "./core-apis";
4
4
  export * from "./plugin";
5
5
  export * from "./plugin-registry";
6
6
  export * from "./components/ExtensionSlot";
7
+ export * from "./use-slot-extensions";
7
8
  export * from "./utils";
8
9
  export * from "./slots";
9
10
  export * from "./use-plugin-route";
package/src/plugin.ts CHANGED
@@ -9,33 +9,72 @@ import type {
9
9
  import type { Signal } from "@checkstack/signal-common";
10
10
 
11
11
  /**
12
- * Extract the context type from a SlotDefinition
12
+ * Extract the context type from a SlotDefinition.
13
13
  */
14
- export type SlotContext<T> = T extends SlotDefinition<infer C> ? C : never;
14
+ export type SlotContext<T> = T extends SlotDefinition<infer C, unknown>
15
+ ? C
16
+ : never;
15
17
 
16
18
  /**
17
- * Type-safe extension that infers component props from the slot definition.
19
+ * Extract the metadata type from a SlotDefinition.
20
+ */
21
+ export type SlotMetadata<T> = T extends SlotDefinition<unknown, infer M>
22
+ ? M
23
+ : never;
24
+
25
+ /**
26
+ * Type-safe extension that infers component props and metadata from the
27
+ * slot definition.
28
+ *
29
+ * The `metadata` field is always declared as optional on the base interface
30
+ * so that aggregate types like `Extension[]` (used in
31
+ * {@link FrontendPlugin.extensions}) accept extensions for slots that don't
32
+ * declare metadata. The required-vs-optional distinction is enforced at
33
+ * registration time by {@link createSlotExtension}, which narrows the input
34
+ * shape based on the slot's metadata parameter.
18
35
  */
19
36
  export interface Extension<
20
- TSlot extends SlotDefinition<unknown> = SlotDefinition<unknown>
37
+ TSlot extends SlotDefinition<unknown, unknown> = SlotDefinition<
38
+ unknown,
39
+ unknown
40
+ >
21
41
  > {
22
42
  id: string;
23
43
  slot: TSlot;
24
44
  component: React.ComponentType<SlotContext<TSlot>>;
45
+ metadata?: SlotMetadata<TSlot>;
25
46
  }
26
47
 
48
+ /**
49
+ * Input shape for `createSlotExtension`. Requires `metadata` when the slot
50
+ * declares a non-`undefined` metadata type, forbids it otherwise.
51
+ */
52
+ type SlotExtensionInput<TSlot extends SlotDefinition<unknown, unknown>> =
53
+ SlotMetadata<TSlot> extends undefined
54
+ ? {
55
+ id: string;
56
+ component: React.ComponentType<SlotContext<TSlot>>;
57
+ metadata?: undefined;
58
+ }
59
+ : {
60
+ id: string;
61
+ component: React.ComponentType<SlotContext<TSlot>>;
62
+ metadata: SlotMetadata<TSlot>;
63
+ };
64
+
27
65
  /**
28
66
  * Helper to create a type-safe extension from a slot definition.
29
- * This ensures the component props match the slot's expected context.
67
+ * Ensures the component props match the slot's expected context and that
68
+ * `metadata` matches the slot's metadata contract (required when the slot
69
+ * declares typed metadata, forbidden otherwise).
30
70
  */
31
- export function createSlotExtension<TSlot extends SlotDefinition<unknown>>(
32
- slot: TSlot,
33
- extension: Omit<Extension<TSlot>, "slot">
34
- ): Extension<TSlot> {
71
+ export function createSlotExtension<
72
+ TSlot extends SlotDefinition<unknown, unknown>
73
+ >(slot: TSlot, extension: SlotExtensionInput<TSlot>): Extension<TSlot> {
35
74
  return {
36
75
  ...extension,
37
76
  slot,
38
- };
77
+ } as Extension<TSlot>;
39
78
  }
40
79
 
41
80
  /**
package/src/slots.ts CHANGED
@@ -1,37 +1,48 @@
1
1
  /**
2
2
  * A type-safe slot definition that can be exported from plugin common packages.
3
- * The context type parameter defines what props extensions will receive.
3
+ *
4
+ * @typeParam TContext - Props passed to every extension component at render time.
5
+ * @typeParam TMetadata - Static descriptor each extension declares at registration time
6
+ * (e.g. label, icon, ordering, access rules). Use `undefined`
7
+ * (the default) when the slot just renders components without
8
+ * per-extension metadata.
4
9
  */
5
- export interface SlotDefinition<TContext = undefined> {
10
+ export interface SlotDefinition<TContext = undefined, TMetadata = undefined> {
6
11
  /** Unique slot identifier, recommended format: "plugin-name.area.purpose" */
7
12
  readonly id: string;
8
13
  /** Phantom type for context type inference - do not use directly */
9
14
  readonly _contextType?: TContext;
15
+ /** Phantom type for metadata type inference - do not use directly */
16
+ readonly _metadataType?: TMetadata;
10
17
  }
11
18
 
12
19
  /**
13
20
  * Creates a type-safe slot definition that can be exported from any package.
14
21
  *
15
22
  * @example
16
- * // In @checkstack/catalog-common
23
+ * // Render-only slot (no metadata)
17
24
  * export const SystemDetailsSlot = createSlot<{ systemId: string }>(
18
25
  * "catalog.system.details"
19
26
  * );
20
27
  *
21
- * // In your frontend plugin
22
- * extensions: [{
23
- * id: "my-plugin.system-details",
24
- * slot: SystemDetailsSlot,
25
- * component: MySystemDetailsExtension, // Receives { systemId: string }
26
- * }]
27
- *
28
- * @param id - Unique slot identifier
29
- * @returns A slot definition that can be used for type-safe extension registration
28
+ * @example
29
+ * // Slot whose extensions declare metadata at registration time
30
+ * interface InfrastructureTabMetadata {
31
+ * label: string;
32
+ * icon: React.ComponentType<{ className?: string }>;
33
+ * readAccess: AccessRule;
34
+ * manageAccess: AccessRule;
35
+ * order?: number;
36
+ * }
37
+ * export const InfrastructureTabsSlot = createSlot<
38
+ * { canUpdate: boolean },
39
+ * InfrastructureTabMetadata
40
+ * >("infrastructure.tabs");
30
41
  */
31
- export function createSlot<TContext = undefined>(
42
+ export function createSlot<TContext = undefined, TMetadata = undefined>(
32
43
  id: string
33
- ): SlotDefinition<TContext> {
34
- return { id } as SlotDefinition<TContext>;
44
+ ): SlotDefinition<TContext, TMetadata> {
45
+ return { id } as SlotDefinition<TContext, TMetadata>;
35
46
  }
36
47
 
37
48
  /**
@@ -51,9 +62,21 @@ export interface UserMenuItemsContext {
51
62
  hasCredentialAccount: boolean;
52
63
  }
53
64
 
54
- export const UserMenuItemsSlot = createSlot<UserMenuItemsContext>(
55
- "core.layout.navbar.user-menu.items"
56
- );
65
+ /**
66
+ * Metadata for user-menu top-section extensions. The optional `group` key
67
+ * lets the menu render extensions under labeled headers (Workspace,
68
+ * Reliability, Configuration, Documentation, Account, or any custom label
69
+ * supplied by a third-party plugin). Extensions without a group render in
70
+ * an unlabeled bucket at the bottom of the top section.
71
+ */
72
+ export interface UserMenuItemsMetadata {
73
+ group?: string;
74
+ }
75
+
76
+ export const UserMenuItemsSlot = createSlot<
77
+ UserMenuItemsContext,
78
+ UserMenuItemsMetadata
79
+ >("core.layout.navbar.user-menu.items");
57
80
  export const UserMenuItemsBottomSlot = createSlot<UserMenuItemsContext>(
58
81
  "core.layout.navbar.user-menu.items.bottom"
59
82
  );
@@ -0,0 +1,38 @@
1
+ import { useEffect, useReducer } from "react";
2
+ import { pluginRegistry } from "./plugin-registry";
3
+ import type { Extension, SlotMetadata } from "./plugin";
4
+ import type { SlotDefinition } from "./slots";
5
+
6
+ /**
7
+ * Strongly-typed extension entry returned by `useSlotExtensions`.
8
+ *
9
+ * `metadata` is typed by the slot's metadata parameter, falling back to
10
+ * `undefined` for slots that declare no metadata.
11
+ */
12
+ export type SlotExtensionEntry<TSlot extends SlotDefinition<unknown, unknown>> =
13
+ Extension<TSlot> & {
14
+ metadata: SlotMetadata<TSlot>;
15
+ };
16
+
17
+ /**
18
+ * Subscribe to all extensions registered for a slot.
19
+ *
20
+ * Re-renders when plugins are registered/unregistered. Use this hook when
21
+ * the consumer needs to do more than just render extensions inline (e.g.
22
+ * read metadata to build a tab bar). For pure render-and-pass-context use,
23
+ * `<ExtensionSlot slot={...} />` remains simpler.
24
+ */
25
+ export function useSlotExtensions<TSlot extends SlotDefinition<unknown, unknown>>(
26
+ slot: TSlot
27
+ ): readonly SlotExtensionEntry<TSlot>[] {
28
+ const [, forceUpdate] = useReducer((x: number) => x + 1, 0);
29
+
30
+ useEffect(() => {
31
+ return pluginRegistry.subscribe(forceUpdate);
32
+ }, []);
33
+
34
+ return pluginRegistry.getExtensions(slot.id) as SlotExtensionEntry<TSlot>[];
35
+ }
36
+
37
+ // Re-export helper types alongside the hook.
38
+ export type { SlotMetadata, SlotContext } from "./plugin";