@checkstack/notification-frontend 0.2.36 → 0.3.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,300 @@
1
1
  # @checkstack/notification-frontend
2
2
 
3
+ ## 0.3.1
4
+
5
+ ### Patch Changes
6
+
7
+ - 50e5f5f: Runtime plugin system: install + uninstall plugins from npm, GitHub releases
8
+ (including private GitHub Enterprise instances), or tarball uploads at
9
+ runtime, with multi-package bundles, dependency-derived compatibility checks,
10
+ multi-instance coordination via a Postgres artifact store, and
11
+ single-coordinator destructive cleanup.
12
+
13
+ Highlights:
14
+
15
+ - New `PluginSource` discriminated union and `PluginInstaller` /
16
+ `PluginInstallerRegistry` interfaces in `@checkstack/backend-api`. The
17
+ GitHub variant accepts an optional `apiBaseUrl` so deployments backed by
18
+ GitHub Enterprise can install from `https://ghe.example.com/api/v3`
19
+ instead of `api.github.com`.
20
+ - New `installPackageMetadataSchema` (Zod) in `@checkstack/common` validates
21
+ every plugin's `package.json` at install time. Required fields: `name`,
22
+ `version`, `description`, `author`, `license`, `checkstack.type`,
23
+ `checkstack.pluginId`. Optional: `checkstack.bundle`,
24
+ `checkstack.usageInstructions`, `checkstack.allowInstallScripts`.
25
+ - New `pluginManagerContract` in `@checkstack/pluginmanager-common` with
26
+ `list`, `previewInstall`, `install`, `previewUninstall`, `uninstall`, and
27
+ `events` procedures.
28
+ - New `@checkstack/pluginmanager-frontend` admin UI: installed-plugins list
29
+ with per-row uninstall (typed-confirmation modal, schema/configs/cascade
30
+ toggles), install page with NPM / Tarball Upload / GitHub Release tabs
31
+ (Catalog tab disabled — coming soon), and an events page surfacing the
32
+ install/uninstall audit log.
33
+ - New `bunx @checkstack/scripts plugin-pack` CLI for plugin authors —
34
+ per-package mode produces an npm-shaped tarball; `--bundle` mode produces
35
+ an outer tarball containing every sibling declared in
36
+ `package.json#checkstack.bundle`. Published to npm so external authors
37
+ can `bunx` it directly without a workspace checkout.
38
+ - Compatibility derived from `package.json#dependencies` ranges
39
+ (`semver.satisfies` against the platform's loaded `@checkstack/*`
40
+ versions) — no separate `compatibility` field.
41
+ - Multi-instance: originator persists artifacts + `plugins` rows + broadcasts
42
+ install/uninstall; receiving instances do in-process register/unregister
43
+ only. Destructive ops (drop schema, delete plugin_configs, delete
44
+ artifacts, delete `plugins` rows) run exactly once on the originator.
45
+ - Fresh-instance bootstrap: `loadPlugins()` hydrates any
46
+ `is_uninstallable=true` plugin missing from `node_modules` from the
47
+ artifact store before normal Phase 1 register.
48
+ - New schema: `plugin_artifacts` (tarball storage), `plugin_install_events`
49
+ (audit/error log). `plugins` extended with `version`, `metadata`,
50
+ `source`, `bundle_id`, `is_primary`. Local plugin sync now writes
51
+ `version` from each plugin's `package.json` so the admin UI shows real
52
+ versions instead of `—`.
53
+ - Tarball-upload endpoint (`POST /api/pluginmanager/upload-tarball`) for
54
+ the install UI; access-gated by `pluginmanager.plugin.manage`.
55
+ - Plugin Manager menu link added to the user menu (main grid, alongside
56
+ Profile / Notification Settings / etc.).
57
+
58
+ Cross-cutting changes:
59
+
60
+ - Backend request/response logging now flows through `rootLogger` (winston)
61
+ instead of `hono/logger`. 5xx responses include the response body inline
62
+ so swallowed early-return errors are visible in the log.
63
+ - The `/api/:pluginId/*` dispatcher now logs which core service is missing
64
+ or which `pluginId` had no metadata when it 500s.
65
+ - New `registerCorePluginMetadata` on `PluginManager` for core routers
66
+ (like the plugin manager itself) that need their metadata visible to the
67
+ RPC dispatcher without going through the full plugin lifecycle.
68
+ - ESLint: `unicorn/no-null` is now disabled globally. Drizzle distinguishes
69
+ between `null` (writes a real SQL NULL) and `undefined` (skip the column
70
+ on insert), so treating them as interchangeable produced latent bugs at
71
+ the persistence boundary. The bulk of the patch-bumped packages above
72
+ reflect lint-fix touches that landed when this rule was relaxed.
73
+ - Workspace-wide license normalization to `Elastic-2.0` (matches
74
+ `LICENSE.md`). Every `package.json` in the workspace now declares the
75
+ same SPDX identifier; the patch bumps capture this.
76
+
77
+ Plugin packages (every `plugins/*`): added a `pack` npm script
78
+ (`bunx @checkstack/scripts plugin-pack`), mirrored each plugin's
79
+ `pluginId` from `plugin-metadata.ts` into `package.json#checkstack.pluginId`
80
+ so install-time validation passes, stubbed any missing required metadata
81
+ fields (`description`, `author`, `license`), and added
82
+ `checkstack.bundle` to multi-package plugin primaries (telegram, rcon, ssh,
83
+ jira, queue-bullmq, queue-memory, cache-memory).
84
+
85
+ Breaking changes:
86
+
87
+ - The legacy single-method `PluginInstaller` interface (`install(packageName)`)
88
+ is removed. Callers must use `coreServices.pluginInstallerRegistry`.
89
+ - The old `pluginAdminContract` and `createPluginAdminRouter` are removed.
90
+ Replaced by `pluginManagerContract` in `@checkstack/pluginmanager-common`
91
+ and `createPluginManagerRouter` in `core/backend`.
92
+ - `@checkstack/test-utils-backend` no longer exports
93
+ `createMockPluginInstaller` / `MockPluginInstaller` (the legacy interface
94
+ it shimmed is gone).
95
+
96
+ Note: bumps are limited to `minor` (for packages with new public API
97
+ surface) and `patch` (for downstream consumers, license normalization,
98
+ and lint fixes). No `major` bumps despite the `PluginInstaller` removal —
99
+ the legacy interface had no third-party consumers in the wild before this
100
+ runtime plugin system landed, and the contract surface is the same shape
101
+ modulo the rename.
102
+
103
+ - Updated dependencies [50e5f5f]
104
+ - @checkstack/common@0.8.0
105
+ - @checkstack/signal-frontend@0.1.1
106
+ - @checkstack/ui@1.7.1
107
+ - @checkstack/auth-frontend@0.5.33
108
+ - @checkstack/frontend-api@0.4.2
109
+ - @checkstack/notification-common@1.0.1
110
+
111
+ ## 0.3.0
112
+
113
+ ### Minor Changes
114
+
115
+ - 32d52c6: Bulk notifications affecting multiple systems and collapse lifecycle events into a single card.
116
+
117
+ Notifications now carry an optional `subjects` array (the entities they affect) and an optional `collapseKey` (so related notifications collapse into one row per recipient). Incidents, maintenances, anomalies, healthchecks, and dependency-impact events route through these new fields, so an incident affecting three systems produces one in-app notification + one external send per subscriber instead of three. Lifecycle updates for the same entity (created → updated → resolved) also collapse, with an expandable "+N updates" timeline.
118
+
119
+ Subject kinds are namespaced as `<pluginId>.<localKind>` and built via type-safe helpers exported from each domain's common package (`createSystemSubject`, `incidentCollapseKey`, etc.). The frontend kind registry (`registerSubjectKind`) lets plugins bind icon + label for their kinds; unknown kinds fall back to a generic chip.
120
+
121
+ All notification strategies (SMTP, Slack, Discord, Teams, Telegram, Pushover, Gotify, Webex, Backstage) render the affected subjects natively in their format (HTML cards, Slack blocks, Discord embed fields, adaptive cards, markdown lists, etc.).
122
+
123
+ - 32d52c6: feat: unified notification-subscription manager dialog driven by spec registry
124
+
125
+ Replaces the bell-toggle UX (which only managed a single legacy
126
+ catalog group) with a modal that lists every notification type
127
+ registered against a target — system or group — and exposes both
128
+ per-type toggles and a bulk "Subscribe to all / Unsubscribe from all"
129
+ action. Both surfaces (system detail page header bell, dashboard group
130
+ header bell) now open the same `NotificationSubscriptionsManager`
131
+ component.
132
+
133
+ **Key change vs. the prior slot-based approach**: rows are now driven
134
+ by `notificationClient.listSubscriptionSpecs` — the backend's spec
135
+ registry is the single source of truth. Previously, a row only
136
+ appeared if a frontend plugin had remembered to register a
137
+ `createNotificationSubscriptionExtension`; this caused silent drift
138
+ (healthcheck and dependency registered backend specs without frontend
139
+ extensions, so the dialog counted them but never rendered rows). Now,
140
+ every spec the platform knows about renders a row using the spec's
141
+ `display` metadata (title, description, iconName resolved via
142
+ `DynamicIcon`).
143
+
144
+ **Sub-controls registry** (`@checkstack/notification-frontend`):
145
+ plugins that want sub-granularity (anomaly's per-field mute list,
146
+ future severity / channel filters) call
147
+ `registerSubscriptionSubControls(spec, Component)` at module load —
148
+ the manager looks the component up by `specId` when expanding a row.
149
+
150
+ **Removed (no compat)**:
151
+
152
+ - `createNotificationSubscriptionExtension` (replaced by the
153
+ spec-driven manager + the SubControls registry)
154
+ - `target.slot` field on `NotificationTarget` and the
155
+ `NotificationTargetInput.slot` parameter on
156
+ `defineNotificationTarget`
157
+ - `SystemNotificationSubscriptionsSlot` and
158
+ `GroupNotificationSubscriptionsSlot` from `@checkstack/catalog-common`
159
+ - `SystemNotificationsCard` from the system detail page's main column
160
+ - `SubscribeButton` wiring on dashboard group cards and the system
161
+ detail page header
162
+
163
+ **Migrated frontends**: anomaly (now registers `AnomalyFieldMuteList`
164
+ via the SubControls registry), incident, maintenance — all dropped
165
+ their `createNotificationSubscriptionExtension` calls. healthcheck and
166
+ dependency now show up automatically via the spec registry — no
167
+ frontend changes needed for them to render.
168
+
169
+ The trigger button reflects aggregate state — filled bell when at
170
+ least one spec is subscribed for the resource, ghost bell when none.
171
+
172
+ - 32d52c6: feat: notification target pattern + per-spec subscriptions
173
+
174
+ Replaces the all-or-nothing catalog system/group notification model with a
175
+ platform-level target pattern. Each notification-emitting plugin declares
176
+ _subscription specs_ against typed _target_ objects exported from the
177
+ target's owning plugin (catalog ships `catalogSystemTarget` and
178
+ `catalogGroupTarget`). Notification-backend handles every per-resource
179
+ group lifecycle, parent-edge inheritance, and legacy-subscription seeding
180
+ — plugins never author groupId helpers, lifecycle hooks, or migration
181
+ code again.
182
+
183
+ **Plugin-author surface area is now ~12 lines per emitter:**
184
+
185
+ ```ts
186
+ // <plugin>-common
187
+ const { defineSubscription } = createSubscriptionFactory(pluginMetadata);
188
+ export const fooSystemSubscription = defineSubscription({
189
+ localId: "system",
190
+ target: catalogSystemTarget,
191
+ display: { title: "Foo Alerts", description: "...", iconName: "Bell" },
192
+ });
193
+
194
+ // <plugin>-backend register()
195
+ env.registerSubscriptionSpecs([fooSystemSubscription]);
196
+ // ^ feeds the plugin loader's dependency sorter — each spec's
197
+ // target.ownerPlugin becomes an implicit init-order dep, so this
198
+ // plugin automatically waits for catalog (the target owner) to
199
+ // finish init + afterPluginsReady before its own runs.
200
+
201
+ // <plugin>-backend afterPluginsReady
202
+ await notificationClient.registerSubscriptionSpec(
203
+ specToRegistration(fooSystemSubscription)
204
+ );
205
+ // dispatch
206
+ await notificationClient.notifyForSubscription({
207
+ specId: fooSystemSubscription.specId,
208
+ resourceKeys: [systemId],
209
+ title,
210
+ body,
211
+ importance,
212
+ action,
213
+ collapseKey,
214
+ subjects,
215
+ });
216
+
217
+ // <plugin>-frontend
218
+ createNotificationSubscriptionExtension({ spec: fooSystemSubscription });
219
+ ```
220
+
221
+ **Migrated plugins**: anomaly, incident, maintenance, healthcheck,
222
+ dependency. Each lost its bespoke `notification-groups.ts`,
223
+ `bootstrap*NotificationGroups`, `ensure*Group`, and inheritance walk —
224
+ all of that is now centralized in notification-backend's
225
+ `subscription-engine`.
226
+
227
+ **Plugin loader change** (`@checkstack/backend-api`,
228
+ `@checkstack/backend`): the register-time API gains
229
+ `env.registerSubscriptionSpecs([...specs])`. The dependency sorter
230
+ walks `spec.target.ownerPlugin` for every declared spec and adds the
231
+ target owner as an init-order dependency of the emitting plugin. This
232
+ guarantees that catalog (the owner of the platform's `system` and
233
+ `group` targets) completes init + afterPluginsReady before any
234
+ emitting plugin tries to register its specs against the notification
235
+ service — no string-prefix heuristics, no manual `dependsOnPlugins`
236
+ list, no stub rows. Plugins that fail to declare their specs at
237
+ register time get a clear `Target type X is not registered. Did the
238
+ emitting plugin declare this spec via env.registerSubscriptionSpecs?`
239
+ error from the dispatcher.
240
+
241
+ **Removed** (no backwards compat):
242
+
243
+ - `catalogClient.notifySystemSubscribers` and
244
+ `catalogClient.notifyManySystemSubscribers`
245
+ - `notificationClient.notifyUsers` and `notificationClient.notifyGroups`
246
+ as direct dispatch primitives — replaced by spec-bound
247
+ `notifyForSubscription`
248
+ - catalog's `bootstrapNotificationGroups` (replaced by
249
+ `bootstrapNotificationTargets`)
250
+
251
+ **Enforcement**: the dispatcher rejects calls referencing unregistered
252
+ specIds, specs owned by other plugins, or resourceKeys that haven't been
253
+ pushed via `upsertNotificationResource`. Display metadata for any
254
+ groupId is recoverable via the spec registry, so audit lists render
255
+ correct labels even when an emitter's frontend isn't loaded.
256
+
257
+ **Per-field anomaly mute** keeps working — it now lives inside the
258
+ generic SubscriptionRow's optional `SubControls` panel
259
+ (`AnomalyFieldMuteList`), exposed through the catalog system detail
260
+ page's notifications card.
261
+
262
+ The catalog system detail page renders a "Notifications" card hosting
263
+ `SystemNotificationSubscriptionsSlot`. The matching group surface is
264
+ not yet rendered — group-level subscriptions are wired end-to-end on
265
+ the backend; a follow-up will add the host UI.
266
+
267
+ **Migration of existing subscribers**: target types declare a
268
+ `legacyGroupIdTemplate`; on first registration of each spec,
269
+ notification-backend reads subscribers from the legacy
270
+ `catalog.system.<id>` / `catalog.group.<id>` groups and seeds the new
271
+ spec groups exactly once per (spec × resource) pair, tracked in
272
+ `subscription_migrations`. Anomaly stays opt-in (its target also
273
+ declares the template, but the user-explicit nature of the original
274
+ opt-in flow means the seeding produces the same set of subscribers
275
+ they already had).
276
+
277
+ ### Patch Changes
278
+
279
+ - 32d52c6: Fix several modal/sheet/overlay closing issues:
280
+
281
+ - Replace the custom `DropdownMenu` container with a Radix-based `Popover` (desktop) and `Sheet` (mobile). The previous mobile implementation suppressed outside-click closing, leaving the notification bell's panel only closable by clicking the bell again. `UserMenu` and `NotificationBell` were updated to the new pattern. Leaf primitives `DropdownMenuItem`, `DropdownMenuLabel`, and `DropdownMenuSeparator` are preserved (now backed by a `MenuCloseContext`) so existing call sites continue to work.
282
+ - Fix `Dialog` outside-click closing. The previous structure made `DialogPrimitive.Content` cover the full viewport, so Radix never registered clicks on the dimmed area as "outside" — only ESC could close the modal. The centering wrapper is now a non-Content `<div>` and the actual modal box is the Content, so outside-click closes correctly. A visible X button is now rendered by default; pass `hideCloseButton` to suppress it (e.g. for the search overlay where it would clash with a custom header).
283
+ - Export a standalone `useIsMobile` hook and a new `Popover` primitive.
284
+ - Prevent Radix's auto-focus-return on `NotificationBell` and `UserMenu` overlays. Closing via an item with a `<Link>` (e.g. "View all notifications") would synchronously refocus the trigger via `onCloseAutoFocus`, stealing focus from the link mid-click on pages where another element held focus and requiring a second click to navigate.
285
+
286
+ - Updated dependencies [32d52c6]
287
+ - Updated dependencies [32d52c6]
288
+ - Updated dependencies [32d52c6]
289
+ - Updated dependencies [32d52c6]
290
+ - Updated dependencies [32d52c6]
291
+ - Updated dependencies [32d52c6]
292
+ - Updated dependencies [32d52c6]
293
+ - @checkstack/notification-common@1.0.0
294
+ - @checkstack/frontend-api@0.4.1
295
+ - @checkstack/auth-frontend@0.5.32
296
+ - @checkstack/ui@1.7.0
297
+
3
298
  ## 0.2.36
4
299
 
5
300
  ### Patch Changes
package/package.json CHANGED
@@ -1,23 +1,24 @@
1
1
  {
2
2
  "name": "@checkstack/notification-frontend",
3
- "version": "0.2.36",
3
+ "version": "0.3.1",
4
+ "license": "Elastic-2.0",
4
5
  "type": "module",
5
6
  "main": "src/index.tsx",
6
7
  "checkstack": {
7
8
  "type": "frontend"
8
9
  },
9
10
  "scripts": {
10
- "typecheck": "tsc --noEmit",
11
+ "typecheck": "tsgo -b",
11
12
  "lint": "bun run lint:code",
12
13
  "lint:code": "eslint . --max-warnings 0"
13
14
  },
14
15
  "dependencies": {
15
- "@checkstack/notification-common": "0.2.9",
16
- "@checkstack/frontend-api": "0.3.11",
17
- "@checkstack/auth-frontend": "0.5.30",
18
- "@checkstack/signal-frontend": "0.0.16",
16
+ "@checkstack/notification-common": "1.0.0",
17
+ "@checkstack/frontend-api": "0.4.1",
18
+ "@checkstack/auth-frontend": "0.5.32",
19
+ "@checkstack/signal-frontend": "0.1.0",
19
20
  "@checkstack/common": "0.7.0",
20
- "@checkstack/ui": "1.6.0",
21
+ "@checkstack/ui": "1.7.0",
21
22
  "react": "^18.2.0",
22
23
  "react-router-dom": "^6.22.0",
23
24
  "lucide-react": "^0.344.0"
@@ -25,7 +26,7 @@
25
26
  "devDependencies": {
26
27
  "typescript": "^5.0.0",
27
28
  "@types/react": "^18.2.0",
28
- "@checkstack/tsconfig": "0.0.5",
29
+ "@checkstack/tsconfig": "0.0.6",
29
30
  "@checkstack/scripts": "0.1.2"
30
31
  }
31
32
  }
@@ -0,0 +1,63 @@
1
+ import { stripMarkdown } from "@checkstack/ui";
2
+ import type { Notification } from "@checkstack/notification-common";
3
+
4
+ interface CollapsedGroupTimelineProps {
5
+ /**
6
+ * The full chronological list of notifications in the group, newest
7
+ * first. The first item (the representative) is rendered above the
8
+ * timeline by the parent, so this component skips it.
9
+ */
10
+ notifications: Notification[];
11
+ variant?: "bell" | "page";
12
+ }
13
+
14
+ /**
15
+ * Compact timeline of older entries in a collapsed notification group.
16
+ * Each row shows the relative time, title, and a one-line body excerpt.
17
+ * The representative (newest) entry is rendered separately by the parent
18
+ * card; this component only renders the historical tail.
19
+ */
20
+ export function CollapsedGroupTimeline({
21
+ notifications,
22
+ variant = "bell",
23
+ }: CollapsedGroupTimelineProps) {
24
+ const older = notifications.slice(1);
25
+ if (older.length === 0) return <></>;
26
+
27
+ const sizeClass = variant === "page" ? "text-sm" : "text-xs";
28
+
29
+ return (
30
+ <div
31
+ className={`mt-2 border-l-2 border-border pl-3 space-y-2 ${sizeClass}`}
32
+ >
33
+ {older.map((n) => (
34
+ <div key={n.id} className="flex flex-col gap-0.5">
35
+ <span className="text-muted-foreground">{formatRelative(n.createdAt)}</span>
36
+ <span className="font-medium text-foreground line-clamp-1">
37
+ {n.title}
38
+ </span>
39
+ {n.body && (
40
+ <span className="text-muted-foreground line-clamp-2">
41
+ {stripMarkdown(n.body)}
42
+ </span>
43
+ )}
44
+ </div>
45
+ ))}
46
+ </div>
47
+ );
48
+ }
49
+
50
+ const RTF = new Intl.RelativeTimeFormat(undefined, { numeric: "auto" });
51
+
52
+ function formatRelative(input: Date | string): string {
53
+ const date = typeof input === "string" ? new Date(input) : input;
54
+ const diffMs = date.getTime() - Date.now();
55
+ const absMin = Math.round(Math.abs(diffMs) / 60_000);
56
+
57
+ if (absMin < 1) return "just now";
58
+ if (absMin < 60) return RTF.format(Math.round(diffMs / 60_000), "minute");
59
+ const absHr = Math.round(absMin / 60);
60
+ if (absHr < 24) return RTF.format(Math.round(diffMs / 3_600_000), "hour");
61
+ const absDay = Math.round(absHr / 24);
62
+ return RTF.format(Math.round(diffMs / 86_400_000), absDay < 30 ? "day" : "month");
63
+ }