@webpieces/http-client-core 0.4.701 → 0.4.703

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@webpieces/http-client-core",
-  "version": "0.4.701",
+  "version": "0.4.703",
   "description": "Isomorphic core of the webpieces HTTP client: the decorator-driven ProxyClient, error translation, and the Proxy trap shared by http-client-node and http-client-browser",
   "type": "commonjs",
   "main": "./src/index.js",
@@ -21,6 +21,6 @@
     "access": "public"
   },
   "dependencies": {
-    "@webpieces/core-util": "0.4.701"
+    "@webpieces/core-util": "0.4.703"
   }
 }

package/src/ClientFilter.d.ts

@@ -58,14 +58,3 @@ export declare class ClientFilterDefinition {
     /** Higher runs OUTERMOST, among THIS client's app filters. See the class doc. */
     priority: number, filter: ClientFilter);
 }
-/**
- * The app filters ONE client installs — a NON-EMPTY list, which is the whole point of the type.
- *
- * `createRpcClient`'s filters argument is optional and typed as this, so "this client has no app
- * filters" has exactly ONE spelling: omit the argument. `[]` would be a second way to say the
- * identical thing, so it is a COMPILE error rather than a discouraged-but-accepted alternative —
- * the same device `JwtRoles`'s `roles` uses, and for the same reason (see
- * `.claude/review/backwards-compatibility.md` shim shape #1: delete the bad case from the type
- * instead of documenting a preference). Pinned in `CreateRpcClientCompileAssertions.ts`.
- */
-export type ClientFilters = readonly [ClientFilterDefinition, ...ClientFilterDefinition[]];

package/src/ClientFilter.js.map

@@ -1 +1 @@
-{"version":3,"file":"ClientFilter.js","sourceRoot":"","sources":["../../../../../packages/http/http-client-core/src/ClientFilter.ts"],"names":[],"mappings":";;;AAwBA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6BG;AACH,MAAa,sBAAsB;IAGX;IACA;IAHpB;IACI,iFAAiF;IACjE,QAAgB,EAChB,MAAoB;QADpB,aAAQ,GAAR,QAAQ,CAAQ;QAChB,WAAM,GAAN,MAAM,CAAc;IACrC,CAAC;CACP;AAND,wDAMC","sourcesContent":["import { Filter } from '@webpieces/core-util';\nimport { ClientRequest } from './ClientRequest';\n\n/**\n * An OUTBOUND filter — the client-side counterpart of the server's `HttpFilter`, and the same\n * `Filter` abstraction from @webpieces/core-util pointed the other way:\n *\n * - server: `Filter<MethodMeta, WpResponse<unknown>>` wraps the controller invocation\n * - client: `Filter<ClientRequest, Response>` wraps the send\n *\n * `REQ` is the mutable {@link ClientRequest}, so a filter can re-point the URL, add headers, or\n * replace the serialized body. `RESP` is the platform `Response`, so a filter can read the status\n * and headers of what came back, short-circuit without sending at all, or invoke the rest of the\n * chain more than once (which is how a redirect is followed under policy).\n *\n * ## One rule: do not consume the body\n *\n * A `Response` body can be read exactly once, and the response body is read AFTER the chain by the\n * engine that turns it into the caller's DTO or typed error. A filter that calls `.json()` or\n * `.text()` on the response it is passing back breaks the call. Read `response.status` and\n * `response.headers` freely; `response.clone()` first if you genuinely need the bytes.\n */\nexport type ClientFilter = Filter<ClientRequest, Response>;\n\n/**\n * ONE registered client filter and the priority it runs at — the client-side twin of the server's\n * `FilterDefinition`, and it carries a priority for the same reason: priority belongs to the\n * REGISTRATION, never to the filter, so the same filter class can sit at different depths in two\n * different clients.\n *\n * Highest priority runs OUTERMOST (first in, last out), matching `FilterMatcher`'s ordering, so a\n * filter with a higher number wraps everything below it.\n *\n * ## Priority orders APP filters against each other, and nothing else\n *\n * The framework's own built-ins (the SSRF guard, the outbound credential minter) are not in this\n * ordering at all: `ProxyClient.initRoutes` appends them BENEATH every app filter, whatever numbers\n * the app chose. So there is no priority — not `Number.MAX_SAFE_INTEGER` — that gets an app filter\n * underneath them, which is the point. The guard must judge, and the minter must sign for, the URL\n * that is actually about to be fetched; a filter that could run below them would be able to move\n * the request after both had spoken.\n *\n\n * ## Two deliberate differences from the server's FilterDefinition\n *\n * 1. It holds an INSTANCE, not a DI class token. Server filters are resolved from the container by\n *    the router; a client filter is constructed at the `createRpcClient` call site, which is code\n *    already inside a DI module and already holding whatever the filter needs (a signing key, a\n *    clock). Adding a container round-trip would buy nothing and would make the filter's collaborators\n *    invisible at the one place a reader looks.\n * 2. There is no filepath pattern. The server matches filters to controllers because ONE router\n *    serves many controllers; a client is bound to exactly ONE contract, so there is nothing to\n *    match against and a pattern would always be a no-op.\n */\nexport class ClientFilterDefinition {\n    constructor(\n        /** Higher runs OUTERMOST, among THIS client's app filters. See the class doc. */\n        public readonly priority: number,\n        public readonly filter: ClientFilter,\n    ) {}\n}\n\n/**\n * The app filters ONE client installs — a NON-EMPTY list, which is the whole point of the type.\n *\n * `createRpcClient`'s filters argument is optional and typed as this, so \"this client has no app\n * filters\" has exactly ONE spelling: omit the argument. `[]` would be a second way to say the\n * identical thing, so it is a COMPILE error rather than a discouraged-but-accepted alternative —\n * the same device `JwtRoles`'s `roles` uses, and for the same reason (see\n * `.claude/review/backwards-compatibility.md` shim shape #1: delete the bad case from the type\n * instead of documenting a preference). Pinned in `CreateRpcClientCompileAssertions.ts`.\n */\nexport type ClientFilters = readonly [ClientFilterDefinition, ...ClientFilterDefinition[]];\n"]}
+{"version":3,"file":"ClientFilter.js","sourceRoot":"","sources":["../../../../../packages/http/http-client-core/src/ClientFilter.ts"],"names":[],"mappings":";;;AAwBA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6BG;AACH,MAAa,sBAAsB;IAGX;IACA;IAHpB;IACI,iFAAiF;IACjE,QAAgB,EAChB,MAAoB;QADpB,aAAQ,GAAR,QAAQ,CAAQ;QAChB,WAAM,GAAN,MAAM,CAAc;IACrC,CAAC;CACP;AAND,wDAMC","sourcesContent":["import { Filter } from '@webpieces/core-util';\nimport { ClientRequest } from './ClientRequest';\n\n/**\n * An OUTBOUND filter — the client-side counterpart of the server's `HttpFilter`, and the same\n * `Filter` abstraction from @webpieces/core-util pointed the other way:\n *\n * - server: `Filter<MethodMeta, WpResponse<unknown>>` wraps the controller invocation\n * - client: `Filter<ClientRequest, Response>` wraps the send\n *\n * `REQ` is the mutable {@link ClientRequest}, so a filter can re-point the URL, add headers, or\n * replace the serialized body. `RESP` is the platform `Response`, so a filter can read the status\n * and headers of what came back, short-circuit without sending at all, or invoke the rest of the\n * chain more than once (which is how a redirect is followed under policy).\n *\n * ## One rule: do not consume the body\n *\n * A `Response` body can be read exactly once, and the response body is read AFTER the chain by the\n * engine that turns it into the caller's DTO or typed error. A filter that calls `.json()` or\n * `.text()` on the response it is passing back breaks the call. Read `response.status` and\n * `response.headers` freely; `response.clone()` first if you genuinely need the bytes.\n */\nexport type ClientFilter = Filter<ClientRequest, Response>;\n\n/**\n * ONE registered client filter and the priority it runs at — the client-side twin of the server's\n * `FilterDefinition`, and it carries a priority for the same reason: priority belongs to the\n * REGISTRATION, never to the filter, so the same filter class can sit at different depths in two\n * different clients.\n *\n * Highest priority runs OUTERMOST (first in, last out), matching `FilterMatcher`'s ordering, so a\n * filter with a higher number wraps everything below it.\n *\n * ## Priority orders APP filters against each other, and nothing else\n *\n * The framework's own built-ins (the SSRF guard, the outbound credential minter) are not in this\n * ordering at all: `ProxyClient.initRoutes` appends them BENEATH every app filter, whatever numbers\n * the app chose. So there is no priority — not `Number.MAX_SAFE_INTEGER` — that gets an app filter\n * underneath them, which is the point. The guard must judge, and the minter must sign for, the URL\n * that is actually about to be fetched; a filter that could run below them would be able to move\n * the request after both had spoken.\n *\n\n * ## Two deliberate differences from the server's FilterDefinition\n *\n * 1. It holds an INSTANCE, not a DI class token. Server filters are resolved from the container by\n *    the router; a client filter is constructed at the `createRpcClient` call site, which is code\n *    already inside a DI module and already holding whatever the filter needs (a signing key, a\n *    clock). Adding a container round-trip would buy nothing and would make the filter's collaborators\n *    invisible at the one place a reader looks.\n * 2. There is no filepath pattern. The server matches filters to controllers because ONE router\n *    serves many controllers; a client is bound to exactly ONE contract, so there is nothing to\n *    match against and a pattern would always be a no-op.\n */\nexport class ClientFilterDefinition {\n    constructor(\n        /** Higher runs OUTERMOST, among THIS client's app filters. See the class doc. */\n        public readonly priority: number,\n        public readonly filter: ClientFilter,\n    ) {}\n}\n"]}

package/src/index.d.ts

@@ -33,4 +33,4 @@ export { TranslatedFailure } from './TranslatedFailure';
 export { ResponseBodyReader } from './ResponseBodyReader';
 export { ClientRequest } from './ClientRequest';
 export { ClientFilterDefinition } from './ClientFilter';
-export type { ClientFilter, ClientFilters } from './ClientFilter';
+export type { ClientFilter } from './ClientFilter';

package/src/index.js.map

@@ -1 +1 @@
-{"version":3,"file":"index.js","sourceRoot":"","sources":["../../../../../packages/http/http-client-core/src/index.ts"],"names":[],"mappings":";AAAA;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG;;;AAEH,6CAA4C;AAAnC,0GAAA,WAAW,OAAA;AACpB,mDAAkD;AAAzC,gHAAA,cAAc,OAAA;AAEvB,uDAAsD;AAA7C,oHAAA,gBAAgB,OAAA;AACzB,iEAAgE;AAAvD,8HAAA,qBAAqB,OAAA;AAC9B,yDAAwD;AAA/C,sHAAA,iBAAiB,OAAA;AAC1B,2DAA0D;AAAjD,wHAAA,kBAAkB,OAAA;AAC3B,kGAAkG;AAClG,kFAAkF;AAClF,gEAAgE;AAChE,iDAAgD;AAAvC,8GAAA,aAAa,OAAA;AACtB,+CAAwD;AAA/C,sHAAA,sBAAsB,OAAA","sourcesContent":["/**\n * @webpieces/http-client-core\n *\n * The ISOMORPHIC core of the webpieces HTTP client — everything that reads an API contract's\n * decorators and turns a method call into an HTTP request, with no opinion about where the\n * magic context comes from or whether a DI container exists.\n *\n * You almost certainly want one of its two environment packages instead:\n * - Server:  @webpieces/http-client-node    (inversify-wired, reads RequestContext, mints OIDC)\n * - Browser: @webpieces/http-client-browser (no DI — React or Angular, app-managed context store)\n *\n * Architecture:\n * ```\n * http-api (defines the contract)\n *    ^\n *    +-- http-routing (server: contract -> handlers)\n *    +-- http-client-core (contract -> HTTP requests)   <- YOU ARE HERE\n *          +-- http-client-node     (RequestContext + Secrets + OIDC + inversify factory)\n *          +-- http-client-browser  (app-held store + plain factory, no DI)\n * ```\n *\n * There is no context/credential/recording seam here at all: ProxyClient is ABSTRACT and asks its\n * subclass for the base URL, the context headers, the log map, the outbound credential, and the\n * recorder. Nothing server-only (RequestContext, Secrets, mintIdToken, TestCaseRecorder) can reach\n * a browser bundle, and nothing browser-only (a ContextReader store) reaches a server.\n */\n\nexport { ProxyClient } from './ProxyClient';\nexport { RequestOutcome } from './RequestOutcome';\nexport type { ApiPrototype } from './ApiPrototype';\nexport { buildClientProxy } from './buildClientProxy';\nexport { ClientErrorTranslator } from './ClientErrorTranslator';\nexport { TranslatedFailure } from './TranslatedFailure';\nexport { ResponseBodyReader } from './ResponseBodyReader';\n// The OUTBOUND filter chain: the mutable request a filter edits, and one registration of a filter\n// at a priority. The `Filter`/`Service`/`FilterChain` abstraction itself lives in\n// @webpieces/core-util, shared with the server's inbound chain.\nexport { ClientRequest } from './ClientRequest';\nexport { ClientFilterDefinition } from './ClientFilter';\nexport type { ClientFilter, ClientFilters } from './ClientFilter';\n"]}
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../../../../../packages/http/http-client-core/src/index.ts"],"names":[],"mappings":";AAAA;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG;;;AAEH,6CAA4C;AAAnC,0GAAA,WAAW,OAAA;AACpB,mDAAkD;AAAzC,gHAAA,cAAc,OAAA;AAEvB,uDAAsD;AAA7C,oHAAA,gBAAgB,OAAA;AACzB,iEAAgE;AAAvD,8HAAA,qBAAqB,OAAA;AAC9B,yDAAwD;AAA/C,sHAAA,iBAAiB,OAAA;AAC1B,2DAA0D;AAAjD,wHAAA,kBAAkB,OAAA;AAC3B,kGAAkG;AAClG,kFAAkF;AAClF,gEAAgE;AAChE,iDAAgD;AAAvC,8GAAA,aAAa,OAAA;AACtB,+CAAwD;AAA/C,sHAAA,sBAAsB,OAAA","sourcesContent":["/**\n * @webpieces/http-client-core\n *\n * The ISOMORPHIC core of the webpieces HTTP client — everything that reads an API contract's\n * decorators and turns a method call into an HTTP request, with no opinion about where the\n * magic context comes from or whether a DI container exists.\n *\n * You almost certainly want one of its two environment packages instead:\n * - Server:  @webpieces/http-client-node    (inversify-wired, reads RequestContext, mints OIDC)\n * - Browser: @webpieces/http-client-browser (no DI — React or Angular, app-managed context store)\n *\n * Architecture:\n * ```\n * http-api (defines the contract)\n *    ^\n *    +-- http-routing (server: contract -> handlers)\n *    +-- http-client-core (contract -> HTTP requests)   <- YOU ARE HERE\n *          +-- http-client-node     (RequestContext + Secrets + OIDC + inversify factory)\n *          +-- http-client-browser  (app-held store + plain factory, no DI)\n * ```\n *\n * There is no context/credential/recording seam here at all: ProxyClient is ABSTRACT and asks its\n * subclass for the base URL, the context headers, the log map, the outbound credential, and the\n * recorder. Nothing server-only (RequestContext, Secrets, mintIdToken, TestCaseRecorder) can reach\n * a browser bundle, and nothing browser-only (a ContextReader store) reaches a server.\n */\n\nexport { ProxyClient } from './ProxyClient';\nexport { RequestOutcome } from './RequestOutcome';\nexport type { ApiPrototype } from './ApiPrototype';\nexport { buildClientProxy } from './buildClientProxy';\nexport { ClientErrorTranslator } from './ClientErrorTranslator';\nexport { TranslatedFailure } from './TranslatedFailure';\nexport { ResponseBodyReader } from './ResponseBodyReader';\n// The OUTBOUND filter chain: the mutable request a filter edits, and one registration of a filter\n// at a priority. The `Filter`/`Service`/`FilterChain` abstraction itself lives in\n// @webpieces/core-util, shared with the server's inbound chain.\nexport { ClientRequest } from './ClientRequest';\nexport { ClientFilterDefinition } from './ClientFilter';\nexport type { ClientFilter } from './ClientFilter';\n"]}