resultar 3.3.0 → 3.4.0

package/README.md

@@ -71,21 +71,6 @@ import type { StrictResult } from 'resultar'
 
 CommonJS `require('resultar')` is not exported.
 
-## Mutation Testing
-
-The core runtime package has a scoped Stryker setup for mutation testing:
-
-```sh
-pnpm --filter resultar test:mutation
-```
-
-The setup lives in [`stryker.conf.json`](./stryker.conf.json) and is intentionally separate from
-`check:full`. It mutates the central runtime files under `src/`, uses the Vitest runner with
-per-test coverage, stores incremental state under `reports/`, and keeps baseline thresholds
-report-only while the mutation score is established. The dedicated
-[`vitest-stryker.config.ts`](./vitest-stryker.config.ts) maps `vite-plus/test` to `vitest` so
-Stryker can run the same tests without the `vp test` bootstrap.
-
 ## Why Teams Use It
 
 This signature hides an expected failure:
@@ -174,6 +159,31 @@ const getPosts = (
     )
 ```
 
+The same flow can be written linearly with `safeTry` when the chain gets harder to scan:
+
+```ts
+const getPostsLinear = (
+  url: string,
+): StrictResultAsync<Post[], FetchPostsError | HttpClientError | ParsePostsError> =>
+  safeTry(async function* () {
+    const response = yield* tryResultAsync(
+      fetch(url),
+      (cause) => new FetchPostsError({ cause }),
+    )
+
+    if (response.status >= 400) {
+      return HttpClientError.err({ status: response.status })
+    }
+
+    const posts = yield* tryResultAsync(
+      response.json() as Promise<Post[]>,
+      (cause) => new ParsePostsError({ cause }),
+    )
+
+    return ok(posts)
+  })
+```
+
 ## Async Control Without A Runtime
 
 The 3.1 async helpers cover common production workflows while keeping plain `Promise` and
@@ -826,6 +836,27 @@ Use `fromPromise` when you already have a promise and need to map rejection into
 const user = fromPromise(loadUserFromRemote(id), (cause) => new FetchUserError({ cause, id }))
 ```
 
+Use `tryResultAsync` when the async boundary is the thing you want to name and document. The object
+form is useful for infrastructure helpers because the task and error mapper stay together:
+
+```ts
+import { createTaggedError, tryResultAsync } from 'resultar'
+import type { StrictResultAsync } from 'resultar'
+
+type AsyncTask = () => Promise<void>
+
+class TaskError extends createTaggedError({
+  name: 'TaskError',
+  message: 'Task failed: $label',
+}) {}
+
+const tryTask = (label: string, task: AsyncTask): StrictResultAsync<void, TaskError> =>
+  tryResultAsync({
+    try: task,
+    catch: (cause) => new TaskError({ cause, label }),
+  })
+```
+
 After that edge conversion, keep your own domain functions returning `Result` values instead of
 throwing expected failures.
 
@@ -952,11 +983,13 @@ Add a check script:
 ```json
 {
   "scripts": {
-    "check": "resultar-check -p tsconfig.json --noEmit"
+    "check": "resultar-check"
   }
 }
 ```
 
+`resultar-check` defaults to `tsconfig.json` and runs TypeScript with no emit.
+
 These fail in the default `must-use` mode:
 
 ```ts
@@ -980,15 +1013,21 @@ Configure Resultar rules in `tsconfig.json`:
 
 ```json
 {
+  "$schema": "./node_modules/resultar-check/schema.json",
   "compilerOptions": {
     "plugins": [{ "name": "resultar-check", "noDiscard": "error" }]
   }
 }
 ```
 
+The package-local schema provides editor completion and validation for `resultar-check` plugin
+options.
+
 Oxlint is intentionally not part of the Resultar rules path; use it only for general linting if your
 project wants it.
 
+For VS Code and Zed setup, use the editor integration section in the `resultar-check` package guide.
+
 ## API Decision Guide
 
 | Need | Use |