Client API: remove Express edge-case handling, simplify allAction, and dependency/tooling updates (v4.4.31)

This release focuses on simplifying the client API surface by removing an Express-specific empty-object workaround in allAction, aligning the runtime and types with a normalized server response shape, and updating dependencies and development tooling. The core motivation is to reduce code complexity and keep the client API in sync with upstream/server behavior (which now consistently returns the expected tuple form). In addition to the allAction changes, this release includes dependency bumps, test and build-tooling adjustments, and several package file normalizations.

New Features

• Affected-items tuple formalization in public API and types
  • Client API actions (action, allAction and location-aware variants) now are documented and typed to return tuples [primaryResult, affectedItems]. This formalizes reporting of items indirectly affected by actions and surfaces the second tuple element in TypeScript types and docs.
  • Documentation updated to include examples and guidance for consuming the affected-items tuple in the API reference.

Improvements

• Simplify allAction factory signature and runtime behavior

  • The getAllActionOperation factory in src/ops/allAction.ts was simplified: removed the outer parameter block that previously accepted api, apiOptions, and utilities. The function now declares the expected parameters directly (action, body, ...), reducing the API surface and improving readability.
  • A file-level eslint exception (/* eslint-disable no-undefined */) was added to allow explicit undefined usage where necessary.
  • Response handling has been streamlined to rely on the server returning the tuple [items, affectedItems]. The code now destructures the HTTP response directly into [items, affectedItems] without pre-processing special cases.
  • Rationale: upstream/server responses have been normalized and no longer send an empty-object placeholder; removing the workaround reduces branching and logging noise.

• Documentation and type updates

  • docs/public/api-reference.md updated to document the Affected Items feature and the new tuple return types with examples and guidance.
  • TypeScript types in src/ClientApi.ts, src/CItemAPI.ts, src/PItemAPI.ts and operation modules updated to include the second tuple element type (Array<PriKey|ComKey|LocKeyArray>) where applicable.
  • LocKeyArray imports and related generic adjustments were added where needed to match the extended API surface.

Bug Fixes

• Remove Express special-case conversion and related warning

  • Previously, responses like {} or the string "{}" were converted to [[], []] in allAction with a warning log. That special-case conversion and the warning were removed; code now expects the server to return the proper tuple shape.
  • Tests that asserted conversion of {} or string "{}" to [[],[]] were removed or updated to reflect the expected direct tuple responses.

• Package JSON formatting normalizations and version updates

  • package.json EOF/format was normalized (ensure trailing newline in final release file). Multiple commits adjusted file endings to maintain consistent formatting across release cycles.
  • Version bumped to 4.4.31 for this release (intermediate development bumps to dev versions occurred during the cycle).

Dependency and Tooling Changes

• Runtime dependency bumps

  • Bumped several @fjell runtime packages to newer patch/minor versions across package.json and package-lock.json, including @fjell/core, @fjell/http-api, @fjell/logging, and @fjell/registry to align with upstream releases.
  • package-lock.json updated to reflect resolved tarballs and integrity fields for bumped entries; duplicate/ inconsistent dependency lines were tidied.

• Linting and eslint tooling updates

  • Bumped @fjell/eslint-config and added/updated @eslint/eslintrc and @eslint/js entries to modernize lint rules and ensure compatibility with current tooling.
  • Small formatting and whitespace adjustments across package.json and source files to improve consistency.

• Build/test infrastructure updates

  • Test environment: added Node fetch/FormData/Blob/File polyfills using undici and node:buffer to provide Node-friendly test globals.
  • Vitest configuration simplified (vitest.config.ts): enabled globals:true, added triple-slash references for types, and simplified many coverage and environment settings.
  • Tests: removed a global mock for @fjell/logging and added vitest-fetch-mock for fetch mocking; tests updated to new allAction behavior.
  • esbuild: pinned esbuild to an exact version (0.25.9) and added npm overrides to avoid version conflicts in the docs build. CI workflows updated to use npm ci for reproducible installs.

Tests

• Unit tests updated to match simplified allAction behavior
  • tests/ops/allAction.test.ts updated: removed test cases that expected conversion of {} or the string "{}" to [[],[]], removed unused type imports, and adjusted mock responses and expectations to use direct array/tuple shapes.
  • New/updated tests verify normal tuple responses, array responses, and that utilities are invoked correctly under the simplified behavior.

Refactoring

• allAction function header and internal flow
  • Removed an intermediate processedResponse variable and related branching; response destructuring is performed directly into items and affectedItems.
  • Reduced branching and logging by trusting server-side normalization.

Developer Experience

• Repository housekeeping
  • Multiple commits normalized trailing newlines in package.json and other package files to keep file endings consistent across platforms and CI.
  • package.json metadata and npm scripts were tidied in several commits to ensure consistent behavior across development and CI.

Breaking Changes

• Runtime behavior change: no automatic conversion of empty-object/string responses
  • Code and tests removed the previous behavior that converted server responses equal to {} or "{}" into [[], []]. If any custom upstream server still returns {} instead of the expected tuple, client code may now receive an unexpected shape and tests may fail. The release assumes upstream/server responses have been normalized to return the tuple [items, affectedItems].
  • Action authors and integrators should ensure servers return the tuple shape described in the updated docs/public/api-reference.md. Consumers should validate response shapes if servers under their control might still send legacy responses.

Migration notes and impact

• If integrations or servers still emit legacy empty-object or string-encoded empty-object responses, update those servers to send the tuple [[], []] when no items are returned. Alternatively, callers can add local guarding/validation until servers are updated.
• TypeScript consumers should update types and expectations to handle the two-element tuple return from action/allAction methods and use the second tuple element (affectedItems) when applicable.

Files / Components Affected (high level)

• src/ops/allAction.ts — simplified factory signature, removed Express workaround, destructure HTTP response directly
• src/ClientApi.ts, src/CItemAPI.ts, src/PItemAPI.ts — type updates to include affected-items tuple
• docs/public/api-reference.md — documentation for affected-items tuple and examples
• tests/ops/allAction.test.ts — test cases updated/removed to reflect new behavior
• package.json / package-lock.json — dependency bumps, formatting normalization, version -> 4.4.31
• vitest.config.ts, tests/setup.ts — test environment and polyfills updated
• CI/Docs build configuration — esbuild pinned, npm ci usage, npm overrides added

Notes

• The code-level logger warning and special-case handling for Express's conversion of [[],[]] to {} were intentionally removed. The commit messages explain the rationale: the upstream server behavior was normalized, making the workaround redundant and noise-producing.
• This release intentionally tightens the contract between client and server: client code now expects the server to return a tuple [items, affectedItems]. If any consumers rely on previous runtime conversions, they should add validation locally or coordinate server-side updates.

If you rely on custom server implementations or run an older server version that returned an empty object for empty-all responses, confirm server behavior and update either the server or client-side guards to maintain compatibility.