@checkstack/dependency-common 0.3.0 → 1.0.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,243 @@
1
1
  # @checkstack/dependency-common
2
2
 
3
+ ## 1.0.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/catalog-common@2.0.1
105
+ - @checkstack/common@0.8.0
106
+ - @checkstack/frontend-api@0.4.2
107
+ - @checkstack/notification-common@1.0.1
108
+ - @checkstack/signal-common@0.2.1
109
+
110
+ ## 1.0.0
111
+
112
+ ### Major Changes
113
+
114
+ - 32d52c6: feat: notification target pattern + per-spec subscriptions
115
+
116
+ Replaces the all-or-nothing catalog system/group notification model with a
117
+ platform-level target pattern. Each notification-emitting plugin declares
118
+ _subscription specs_ against typed _target_ objects exported from the
119
+ target's owning plugin (catalog ships `catalogSystemTarget` and
120
+ `catalogGroupTarget`). Notification-backend handles every per-resource
121
+ group lifecycle, parent-edge inheritance, and legacy-subscription seeding
122
+ — plugins never author groupId helpers, lifecycle hooks, or migration
123
+ code again.
124
+
125
+ **Plugin-author surface area is now ~12 lines per emitter:**
126
+
127
+ ```ts
128
+ // <plugin>-common
129
+ const { defineSubscription } = createSubscriptionFactory(pluginMetadata);
130
+ export const fooSystemSubscription = defineSubscription({
131
+ localId: "system",
132
+ target: catalogSystemTarget,
133
+ display: { title: "Foo Alerts", description: "...", iconName: "Bell" },
134
+ });
135
+
136
+ // <plugin>-backend register()
137
+ env.registerSubscriptionSpecs([fooSystemSubscription]);
138
+ // ^ feeds the plugin loader's dependency sorter — each spec's
139
+ // target.ownerPlugin becomes an implicit init-order dep, so this
140
+ // plugin automatically waits for catalog (the target owner) to
141
+ // finish init + afterPluginsReady before its own runs.
142
+
143
+ // <plugin>-backend afterPluginsReady
144
+ await notificationClient.registerSubscriptionSpec(
145
+ specToRegistration(fooSystemSubscription)
146
+ );
147
+ // dispatch
148
+ await notificationClient.notifyForSubscription({
149
+ specId: fooSystemSubscription.specId,
150
+ resourceKeys: [systemId],
151
+ title,
152
+ body,
153
+ importance,
154
+ action,
155
+ collapseKey,
156
+ subjects,
157
+ });
158
+
159
+ // <plugin>-frontend
160
+ createNotificationSubscriptionExtension({ spec: fooSystemSubscription });
161
+ ```
162
+
163
+ **Migrated plugins**: anomaly, incident, maintenance, healthcheck,
164
+ dependency. Each lost its bespoke `notification-groups.ts`,
165
+ `bootstrap*NotificationGroups`, `ensure*Group`, and inheritance walk —
166
+ all of that is now centralized in notification-backend's
167
+ `subscription-engine`.
168
+
169
+ **Plugin loader change** (`@checkstack/backend-api`,
170
+ `@checkstack/backend`): the register-time API gains
171
+ `env.registerSubscriptionSpecs([...specs])`. The dependency sorter
172
+ walks `spec.target.ownerPlugin` for every declared spec and adds the
173
+ target owner as an init-order dependency of the emitting plugin. This
174
+ guarantees that catalog (the owner of the platform's `system` and
175
+ `group` targets) completes init + afterPluginsReady before any
176
+ emitting plugin tries to register its specs against the notification
177
+ service — no string-prefix heuristics, no manual `dependsOnPlugins`
178
+ list, no stub rows. Plugins that fail to declare their specs at
179
+ register time get a clear `Target type X is not registered. Did the
180
+ emitting plugin declare this spec via env.registerSubscriptionSpecs?`
181
+ error from the dispatcher.
182
+
183
+ **Removed** (no backwards compat):
184
+
185
+ - `catalogClient.notifySystemSubscribers` and
186
+ `catalogClient.notifyManySystemSubscribers`
187
+ - `notificationClient.notifyUsers` and `notificationClient.notifyGroups`
188
+ as direct dispatch primitives — replaced by spec-bound
189
+ `notifyForSubscription`
190
+ - catalog's `bootstrapNotificationGroups` (replaced by
191
+ `bootstrapNotificationTargets`)
192
+
193
+ **Enforcement**: the dispatcher rejects calls referencing unregistered
194
+ specIds, specs owned by other plugins, or resourceKeys that haven't been
195
+ pushed via `upsertNotificationResource`. Display metadata for any
196
+ groupId is recoverable via the spec registry, so audit lists render
197
+ correct labels even when an emitter's frontend isn't loaded.
198
+
199
+ **Per-field anomaly mute** keeps working — it now lives inside the
200
+ generic SubscriptionRow's optional `SubControls` panel
201
+ (`AnomalyFieldMuteList`), exposed through the catalog system detail
202
+ page's notifications card.
203
+
204
+ The catalog system detail page renders a "Notifications" card hosting
205
+ `SystemNotificationSubscriptionsSlot`. The matching group surface is
206
+ not yet rendered — group-level subscriptions are wired end-to-end on
207
+ the backend; a follow-up will add the host UI.
208
+
209
+ **Migration of existing subscribers**: target types declare a
210
+ `legacyGroupIdTemplate`; on first registration of each spec,
211
+ notification-backend reads subscribers from the legacy
212
+ `catalog.system.<id>` / `catalog.group.<id>` groups and seeds the new
213
+ spec groups exactly once per (spec × resource) pair, tracked in
214
+ `subscription_migrations`. Anomaly stays opt-in (its target also
215
+ declares the template, but the user-explicit nature of the original
216
+ opt-in flow means the seeding produces the same set of subscribers
217
+ they already had).
218
+
219
+ ### Minor Changes
220
+
221
+ - 32d52c6: Bulk notifications affecting multiple systems and collapse lifecycle events into a single card.
222
+
223
+ 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.
224
+
225
+ 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.
226
+
227
+ 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.).
228
+
229
+ ### Patch Changes
230
+
231
+ - Updated dependencies [32d52c6]
232
+ - Updated dependencies [32d52c6]
233
+ - Updated dependencies [32d52c6]
234
+ - Updated dependencies [32d52c6]
235
+ - Updated dependencies [32d52c6]
236
+ - Updated dependencies [32d52c6]
237
+ - @checkstack/notification-common@1.0.0
238
+ - @checkstack/catalog-common@2.0.0
239
+ - @checkstack/frontend-api@0.4.1
240
+
3
241
  ## 0.3.0
4
242
 
5
243
  ### Minor Changes
package/package.json CHANGED
@@ -1,6 +1,7 @@
1
1
  {
2
2
  "name": "@checkstack/dependency-common",
3
- "version": "0.3.0",
3
+ "version": "1.0.1",
4
+ "license": "Elastic-2.0",
4
5
  "type": "module",
5
6
  "exports": {
6
7
  ".": {
@@ -9,18 +10,20 @@
9
10
  },
10
11
  "dependencies": {
11
12
  "@checkstack/common": "0.7.0",
12
- "@checkstack/frontend-api": "0.3.11",
13
- "@checkstack/signal-common": "0.1.10",
13
+ "@checkstack/catalog-common": "2.0.0",
14
+ "@checkstack/frontend-api": "0.4.1",
15
+ "@checkstack/notification-common": "1.0.0",
16
+ "@checkstack/signal-common": "0.2.0",
14
17
  "@orpc/contract": "^1.13.14",
15
18
  "zod": "^4.2.1"
16
19
  },
17
20
  "devDependencies": {
18
21
  "typescript": "^5.7.2",
19
- "@checkstack/tsconfig": "0.0.5",
22
+ "@checkstack/tsconfig": "0.0.6",
20
23
  "@checkstack/scripts": "0.1.2"
21
24
  },
22
25
  "scripts": {
23
- "typecheck": "tsc --noEmit",
26
+ "typecheck": "tsgo -b",
24
27
  "lint": "bun run lint:code",
25
28
  "lint:code": "eslint . --max-warnings 0"
26
29
  },
package/src/index.ts CHANGED
@@ -26,6 +26,7 @@ export {
26
26
  type NodePosition,
27
27
  } from "./schemas";
28
28
  export * from "./plugin-metadata";
29
+ export * from "./notifications";
29
30
  export { dependencyRoutes } from "./routes";
30
31
 
31
32
  // =============================================================================
@@ -0,0 +1,38 @@
1
+ import {
2
+ createCollapseKeyBuilder,
3
+ createSubscriptionFactory,
4
+ } from "@checkstack/notification-common";
5
+ import {
6
+ catalogSystemTarget,
7
+ catalogGroupTarget,
8
+ } from "@checkstack/catalog-common";
9
+ import { pluginMetadata } from "./plugin-metadata";
10
+
11
+ export const dependencyUpstreamCollapseKey = createCollapseKeyBuilder(
12
+ pluginMetadata,
13
+ "upstream",
14
+ );
15
+
16
+ const { defineSubscription } = createSubscriptionFactory(pluginMetadata);
17
+
18
+ export const dependencySystemSubscription = defineSubscription({
19
+ localId: "system",
20
+ target: catalogSystemTarget,
21
+ display: {
22
+ title: "Dependency Impact",
23
+ description:
24
+ "Alerts when this system is impacted by an upstream dependency outage.",
25
+ iconName: "GitBranch",
26
+ },
27
+ });
28
+
29
+ export const dependencyGroupSubscription = defineSubscription({
30
+ localId: "group",
31
+ target: catalogGroupTarget,
32
+ display: {
33
+ title: "Dependency Impact",
34
+ description:
35
+ "Alerts when any system in this group is impacted by an upstream dependency outage.",
36
+ iconName: "GitBranch",
37
+ },
38
+ });
package/tsconfig.json CHANGED
@@ -2,5 +2,22 @@
2
2
  "extends": "@checkstack/tsconfig/common.json",
3
3
  "include": [
4
4
  "src"
5
+ ],
6
+ "references": [
7
+ {
8
+ "path": "../catalog-common"
9
+ },
10
+ {
11
+ "path": "../common"
12
+ },
13
+ {
14
+ "path": "../frontend-api"
15
+ },
16
+ {
17
+ "path": "../notification-common"
18
+ },
19
+ {
20
+ "path": "../signal-common"
21
+ }
5
22
  ]
6
23
  }