resultar 3.8.0 → 3.9.0

package/README.md

@@ -494,13 +494,12 @@ The callback runs only when the task executes. Use `tryPromise({ try, catch })`
 specific error type; both forms receive the runtime signal and preserve interruption semantics.
 
 Workflows can request typed services with `yield*` and receive them at the boundary. Pass the service
-type and its literal identifier so the named environment remains checked:
+type first, then let the second call infer its literal identifier:
 
 ```ts
 const Database = ResultTask.service<
-  { findUser: (id: string) => Promise<string> },
-  'Database'
->('Database')
+  { findUser: (id: string) => Promise<string> }
+>()('Database')
 
 const taskWithDatabase = ResultTask.gen(function* () {
   const database = yield* Database
@@ -529,6 +528,16 @@ await ResultTask.runResult(readyWithOne)
 await ResultTask.runResult(readyWithAll)
 ```
 
+The direct form `ResultTask.service<DatabaseContract, 'Database'>('Database')` remains supported.
+The curried form can also be yielded inline: `yield* ResultTask.service<DatabaseContract>()('Database')`.
+Requirements belong to `R` in `ResultTask<T, E, R>`; `Result` has no service lookup API.
+
+Every tag creation has its own symbol identity. Inline tags resolve through named environments
+(`provideServices` or the DI module). `provideService(token, value)` supplies both an exact token binding and a named fallback.
+Reuse the same token to select its exact binding when identifiers collide; a separately created
+same-name tag can resolve the named fallback. Exact token bindings take precedence. For class services and explicit dependency maps, see
+[`Service.require` and `requires` in resultar-di](../di/README.md#class-services-and-explicit-requirements).
+
 Infrastructure such as a dependency-injection adapter can resolve service tags lazily with
 `provideServiceResolver(task, { Logger: () => loggerTask })`. Each required identifier has a
 typed lazy provider. Provider errors and external requirements remain in the resulting task type;

package/dist/agent/SKILL.md

@@ -42,7 +42,10 @@ work, typed service requirements, or owned resource lifetimes. Preserve existing
 contracts; converting an already-started Promise or ResultAsync cannot undo its execution.
 `ResultTask.runResult` can reject on defects, interruption, and composite causes. Use `runExit`
 when the boundary must inspect every exit without rejection. See [API details](references/api.md).
-For DI, Hono and Fastify, read [services and HTTP scopes](references/services.md).
+For DI, Hono and Fastify, read [services and HTTP scopes](references/services.md). Use
+`ResultTask.service<T>()(name)` or DI `Service.require<T>()(name)` for inferred identifiers. Class
+services support optional `requires` with a factory returning ResultTask; generator-only `make`
+remains available. Check installed versions before using these overloads.
 
 ## Apply Opinionated Defaults
 

package/dist/agent/references/services.md

@@ -1,9 +1,22 @@
 # Typed services and HTTP scopes
 
 Read the installed `resultar-di/README.md`, `resultar-hono/README.md` and `resultar-fastify/README.md` for the exact companion
-versions. The primary DI exports are `createModule`, `service`, and `resource`; class tokens and
-named factory overloads belong to `resultar-di/advanced`.
+versions. The application DI helpers are `createModule`, `service`, `Service`, and `resource`.
+Named factory overloads and low-level adapter access use the same `resultar-di` entry point.
+The former `/advanced` subpath has been removed; migrate existing imports to `resultar-di`.
 
+- Use `ResultTask.service<Contract>()('name')` in core or `Service.require<Contract>()('name')`
+  in DI to infer the literal identifier. The direct core overload remains supported; do not invent
+  `Result.service`. Service requirements are represented by `R` in `ResultTask<T, E, R>`.
+- Declare class services with `Service('name', { requires: { alias: Token }, make: ({ alias }) =>
+  ResultTask.sync(...) })`. The readonly dependency object is inferred; `make` must return a
+  ResultTask, never a plain object or Promise. Use `ResultTask.gen` for initialization with more
+  steps. Without `requires`, pass a task directly as `make` and yield requirements inline or by token.
+  Both forms support `Service<Contract>()('name', definition)`.
+- Keep provider registration explicit. `requires` does not acquire or register dependencies.
+  Inline tokens resolve by name in DI or `provideServices`; core `provideService` supplies an exact
+  token binding plus a named fallback. Reuse the same token for exact identity when identifiers
+  collide; separately created tags can resolve the named fallback.
 - Register a service token with `.singleton(Token)`, `.scoped(Token)`, or `.transient(Token)`.
   Dependency objects are inferred from tokens. Use `service(name, task)` for asynchronous
   initialization; an async function passed as an ordinary factory is a defect in the contract.
@@ -11,10 +24,26 @@ named factory overloads belong to `resultar-di/advanced`.
   live resource from a completed scope returns a resource whose finalizer has already run.
 - Use `createHonoApp` for Hono routes. Ordinary `await` and `result.match` inside a route are valid;
   generator-specific restrictions do not apply to a route body.
+  Export `type AppHono = Hono<{ Bindings: InferRequestServices<typeof createApplication> }>`
+  from `main.ts`, using `InferRequestServices` from `resultar-hono`. Separate route files import
+  `AppHono` with `import type` and receive `(app: AppHono)`. Bindings follow the application
+  selection without repeating service tokens.
+- `bindings` is optional in `createHonoApp`, `createFastifyApp` and `createFastifyPlugin`.
+  Omission selects all registrations; an explicit list restricts the view and `[]` selects none.
+  Selected services resolve before the handler, preserving each lifetime and resource ownership.
+  Unused default-selected services can still fail acquisition and prevent the handler.
+  Fastify `appBindings` continues to default to `[]`; locals satisfy requirements without being
+  automatically exposed as registrations. The Hono middleware API still takes explicit keys.
 - Use `createHonoServices(module).middleware(keys, { locals })` to add services to an existing Hono
   router. Inline route middleware infers `c.var.services` while preserving `c.env` and native RPC
   responses. Install one services middleware per request; consume/cancel responses before `close()`.
-- Use `createFastifyPlugin({ services, bindings, appBindings?, locals? })` for native Fastify routes.
+- Use `createFastifyApp({ services, bindings? }, configure)` for a new native Fastify application,
+  or `createFastifyPlugin({ services, bindings?, appBindings?, locals? })` for an existing server.
+  Derive `FastifyRequest.services` once with
+  `InferRequestServices<typeof createApplication>` directly in `main.ts` or in a declaration
+  file included by TypeScript. `InferAppServices` also accepts the application return type. Both follow the
+  selected bindings or custom exposed views; no global types or runtime metadata are installed
+  by the adapter. Native routes and autoload do not need wrappers.
   `app.services` contains the selected startup singletons; `request.services` is available from
   `preHandler` through response completion. Register authentication providing locals earlier.
   Infer decorators with `InferAppServices` / `InferRequestServices`; augment Fastify in the application
@@ -37,3 +66,23 @@ named factory overloads belong to `resultar-di/advanced`.
 For a complete runnable pattern, see the workspace `examples/hono/` and `examples/resultar/`
 application lifecycle examples. The distributed guide includes the checked core recipe at
 `examples/workflow.mjs`; use the published declarations to adapt companion integrations.
+
+## Framework DI exports
+
+`resultar-fastify` and `resultar-hono` reexport the application DI helpers: `createModule`, `Service`,
+`service`, `resource`, plus `HttpApplication`, `ServiceClass`, `ServiceLifetime`, `ServiceModule`
+and `ServiceScope` types. In framework-specific code, import these from the adapter together
+with its integration helpers. Core APIs such as `ResultTask` still come from `resultar`.
+Keep direct `resultar-di` imports and dependencies in framework-independent shared code and
+for framework adapter helpers such as `withProvider` and `useServiceAccess`. Check the installed adapter exports before using this convenience
+with older versions.
+
+## Runnable HTTP examples
+
+The maintained Fastify and Hono examples each contain their own `services.ts`, `routes.ts`
+and `main.ts`. `services.ts` declares `Cache`, `UsersRepository` and `Users` classes,
+function-based `Health`, and the `createServices` module factory. `main.ts` omits
+`bindings` and owns framework typing and startup. The default request view includes all
+registered services, including the cache and repository. Do not introduce
+a shared package, separate `users.ts` or an extra `app.ts` for these small examples.
+Start either example with `pnpm dev` from its directory; `PORT` defaults to 3000.

package/dist/agent/versions.json

@@ -1,10 +1,10 @@
 {
   "resultar-check": "3.2.0",
-  "resultar-di": "0.2.0",
-  "resultar-fastify": "0.2.0",
-  "resultar-hono": "0.2.0",
+  "resultar-di": "0.3.0",
+  "resultar-fastify": "0.3.0",
+  "resultar-hono": "0.3.0",
   "resultar-request": "0.1.2",
   "resultar-request-typebox": "0.1.2",
   "resultar-request-zod": "0.1.2",
-  "resultar": "3.8.0"
+  "resultar": "3.9.0"
 }

package/dist/index.d.ts

@@ -898,6 +898,8 @@ export declare class ResultTask<out A, out E = never, out R = never> extends Pip
   static scoped<A, E, R>(task: ResultTask<A, E, R>): ResultTask<A, E | ScopeError<R>, WithoutScope<R>>;
   /** Creates a service tag that can be requested with `yield*` inside `ResultTask.gen`. */
   static service<Service, const Identifier extends string>(identifier: Identifier): ServiceTag<Identifier, Service>;
+  /** Infers the literal identifier after specifying the service contract. */
+  static service<Service>(): <const Identifier extends string>(identifier: Identifier) => ServiceTag<Identifier, Service>;
   /** Builds a task from a generator and short-circuits on the first failed task. */
   static gen<Yield, Return, Next>(body: () => Generator<Yield, Return, Next>): ResultTask<Return, GeneratorError<Yield>, GeneratorRequirements<Yield>>;
   /** Maps the success value without executing the task. */

package/dist/index.js

@@ -1222,8 +1222,8 @@ var ResultTask = class ResultTask extends Pipeable {
 			return interruptSuccess(await scope.close(interruptSuccess(exit, context.signal)), context.signal);
 		});
 	}
-	/** Creates a service tag that can be requested with `yield*` inside `ResultTask.gen`. */
 	static service(identifier) {
+		if (identifier === void 0) return (name) => new ServiceTagValue(name);
 		return new ServiceTagValue(identifier);
 	}
 	/** Builds a task from a generator and short-circuits on the first failed task. */

package/dist/llms.txt

@@ -1,4 +1,4 @@
-# Resultar 3.8.0
+# Resultar 3.9.0
 
 Documentation bundled with this package version. Installed declarations remain authoritative.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "resultar",
-  "version": "3.8.0",
+  "version": "3.9.0",
   "description": "Result pattern for TypeScript",
   "keywords": [
     "error-handling",
@@ -49,7 +49,7 @@
     "fallow": "3.25.0",
     "tsx": "4.23.13",
     "typescript": "7.0.2",
-    "vite-plus": "0.3.1",
+    "vite-plus": "0.3.2",
     "vitest": "4.1.11"
   },
   "peerDependencies": {