@systemfsoftware/stryker-js-plugin-interface 4.0.0 → 6.0.0

package/CHANGELOG.md

@@ -0,0 +1,94 @@
+# @systemfsoftware/stryker-js-plugin-interface
+
+## 6.0.0
+
+### Major Changes
+
+- `testRunner`, `checkers`, and `ignorers` now carry the plugin and its options together.
+
+  - `testRunner` is `'command'`, `'vm'`, or `{ plugin, options?, nodeArgs? }`.
+  - `checkers` is `{ plugin, options?, nodeArgs? }[]`. Each checker is its own plugin.
+  - `ignorers` is plugin file URLs. Every ignorer those modules export runs. There is no separate name list.
+  - Put Vitest settings on `testRunner.options` (`configFile`, `dir`, `related`). There is no `vitest` block.
+  - Put TypeScript checker settings on that checker's `options` (`prioritizePerformanceOverAccuracy`). There is no `typescriptChecker` block.
+
+  Before:
+
+  ```ts
+  export default defineConfig({
+    testRunner: 'vitest',
+    checkers: ['typescript'],
+    plugins: [
+      import.meta.resolve('@systemfsoftware/stryker-js-vitest-runner'),
+      import.meta.resolve('@systemfsoftware/stryker-js-typescript-checker'),
+      import.meta.resolve('@systemfsoftware/stryker-ignorer-effect-schema-declarations'),
+    ],
+    vitest: { configFile: 'vitest.config.ts' },
+    typescriptChecker: { prioritizePerformanceOverAccuracy: true },
+    ignorers: ['effect-schema-declarations'],
+  })
+  ```
+
+  After:
+
+  ```ts
+  export default defineConfig({
+    testRunner: {
+      plugin: import.meta.resolve('@systemfsoftware/stryker-js-vitest-runner'),
+      options: { configFile: 'vitest.config.ts' },
+    },
+    checkers: [
+      {
+        plugin: import.meta.resolve('@systemfsoftware/stryker-js-typescript-checker'),
+        options: { prioritizePerformanceOverAccuracy: true },
+      },
+    ],
+    ignorers: [
+      import.meta.resolve('@systemfsoftware/stryker-ignorer-effect-schema-declarations'),
+    ],
+  })
+  ```
+
+- Plugin entries in `plugins` and `appendPlugins` are now the entrypoints
+  themselves, as `file:` URLs, instead of package names Stryker resolved for you.
+
+  Stryker resolved every specifier against its own module before, so a plugin the
+  project had installed was only found when Node happened to walk to the right
+  `node_modules` from Stryker's location — which is not the project's location for
+  a global install, an `npx` run, or a strict isolated store. The project now
+  resolves each plugin itself, in the config module where the project's own
+  dependencies are visible:
+
+  ```ts
+  import { defineConfig } from '@systemfsoftware/stryker-js/config'
+
+  export default defineConfig({
+    plugins: [import.meta.resolve('@acme/stryker-runner')],
+  })
+  ```
+
+  The `--plugins` and `--appendPlugins` flags take the same resolved URLs. A value
+  that is not a `file:` URL is refused with the entry named.
+
+  Stryker no longer reports an unresolved specifier as a warning it can continue
+  past, because it no longer resolves one: a plugin that cannot be loaded stops
+  the run and names the entry, and a plugin that loads but contributes nothing is
+  still reported as before.
+
+## 5.0.0
+
+### Major Changes
+
+- The plugin system now runs each configured TestRunner/Checker/Reporter plugin in its own spawned process over an @effect/rpc wire: plugins load from the project's config-declared specifiers (no glob discovery), boundary failures are typed errors, and plugin spans link into the host trace. Breaking: the in-process plugin Layer contract is removed.
+
+- `@systemfsoftware/stryker-js` is renamed to `@systemfsoftware/stryker-js-language`, and the plugin boundary now ships as the two packages `@systemfsoftware/stryker-js-plugin-interface` and `@systemfsoftware/stryker-js-plugin-runtime`.
+
+  `@systemfsoftware/stryker-js-plugin-interface` owns the contract both sides of the process split agree on: the per-kind `@effect/rpc` groups (`TestRunnerRpcs`, `CheckerRpcs`, `ReporterRpcs`), the boundary payload schemas, the typed boundary errors (`BoundaryPayloadRejected`, `BoundaryUnrecognizedSignal`), the spawn contract (`WorkerPluginKind`, `WorkerPluginSpawnSchema`, `WorkerEntryUrl`), and the trace-context contract (`TraceContextMiddleware`, `PropagatedTrace`, `TracedRpc`, `formatTraceparent`, `parseTraceparent`, `TraceContextReference`, `TRACEPARENT_HEADER`, `TRACESTATE_HEADER`).
+
+  `@systemfsoftware/stryker-js-plugin-runtime` owns what a plugin process actually runs: the worker server layer a plugin's `main.ts` launches (`workerServerLayer`, `nodeModuleLayer`), the worker and host OTel bootstraps (`startWorkerTelemetry`, `startHostTelemetry`), the worker-options wire codec (`encodeWorkerOptions`, `decodeWorkerOptions`, `readWorkerOptionsFromEnv`), and the trace-context middleware implementations (`layerTraceContextClient`, `layerTraceContextServer`, `withLinkedSpan`, `tracePartsOf`).
+
+  To migrate, update the package name on every import that is not a plugin symbol to `@systemfsoftware/stryker-js-language`; install `@systemfsoftware/stryker-js-plugin-interface` and import the contract symbols listed above from it, and install `@systemfsoftware/stryker-js-plugin-runtime` for the worker-side symbols. The former in-process surface (`declarePlugin`, `composePlugins`, `PluginContribution`, `PluginLayerContribution`, `PluginKind`, `PluginEnvironment`, `RunConfiguration`, `SandboxDirectory`) no longer exists: a plugin now declares `strykerPlugins: readonly { kind, name }[]` and a worker entry exported under `./worker` (or a `bin`) that serves the per-kind `RpcServer`.
+
+### Patch Changes
+
+- Maintenance release. Every published entry point, export, option, and behaviour is exactly as it was.

package/README.md

@@ -5,8 +5,8 @@ checker, or reporter — ships a spawn entrypoint whose target hosts an `RpcServ
 for its kind's `@effect/rpc` group; the host resolves that entrypoint from the
 project's config, spawns it, and drives it over NDJSON. Every payload crossing
 the boundary is a schema this package owns, and every failure is a typed variant.
-The concept modules a plugin implements live in
-`@systemfsoftware/stryker-js-language`.
+The concept modules a plugin implements — the test-runner and checker services and
+the schemas they carry — ship from this package too.
 
 The boundary ships as two packages: