@stackables/bridge@2.2.1

Patch Changes

• Updated dependencies [b213e9f, b213e9f, fc6c619, fc6c619, 2243c7e, 8e5b2e2]:
  • @stackables/bridge-parser@1.4.0
  • @stackables/bridge-core@1.5.0
  • @stackables/bridge-graphql@1.2.0
  • @stackables/bridge-stdlib@1.5.2

@stackables/bridge-types@1.1.0

Minor Changes

• #100 8e5b2e2 Thanks @aarne! - Add ToolMetadata — per-tool observability controls

  Tools can now attach a .bridge property to declare how the engine should
  instrument them, imported as ToolMetadata from @stackables/bridge.

  import type { ToolMetadata } from "@stackables/bridge";
  
  myTool.bridge = {
    trace: false, // skip OTel span for this tool
    log: {
      execution: "info", // log successful calls at info level
      errors: "error", // log failures at error level (default)
    },
  } satisfies ToolMetadata;

@stackables/bridge-stdlib@1.5.2

Patch Changes

• #103 fc6c619 Thanks @aarne! - Fix filter, find, toLowerCase, toUpperCase, trim, and length crashing on unexpected input types

• #100 8e5b2e2 Thanks @aarne! - Add ToolMetadata — per-tool observability controls

  Tools can now attach a .bridge property to declare how the engine should
  instrument them, imported as ToolMetadata from @stackables/bridge.

  import type { ToolMetadata } from "@stackables/bridge";
  
  myTool.bridge = {
    trace: false, // skip OTel span for this tool
    log: {
      execution: "info", // log successful calls at info level
      errors: "error", // log failures at error level (default)
    },
  } satisfies ToolMetadata;

• Updated dependencies [8e5b2e2]:

  • @stackables/bridge-types@1.1.0

@stackables/bridge-parser@1.4.0

Minor Changes

• #104 b213e9f Thanks @copilot-swe-agent! - Multi-Level Control Flow (break N, continue N)

  When working with deeply nested arrays (e.g., mapping categories that contain lists of products), you may want an error deep inside the inner array to skip the outer array element.

  You can append a number to break or continue to specify how many loop levels the signal should pierce.

Patch Changes

• Updated dependencies [b213e9f, fc6c619, fc6c619, 2243c7e, 8e5b2e2]:
  • @stackables/bridge-core@1.5.0
  • @stackables/bridge-stdlib@1.5.2

@stackables/bridge-graphql@1.2.0

Minor Changes

• #104 b213e9f Thanks @copilot-swe-agent! - Support optional lookahead resolver with compiler

Patch Changes

• Updated dependencies [b213e9f, fc6c619, fc6c619, 2243c7e, 8e5b2e2]:
  • @stackables/bridge-core@1.5.0
  • @stackables/bridge-stdlib@1.5.2

@stackables/bridge-core@1.5.0

Minor Changes

• #104 b213e9f Thanks @copilot-swe-agent! - Multi-Level Control Flow (break N, continue N)

  When working with deeply nested arrays (e.g., mapping categories that contain lists of products), you may want an error deep inside the inner array to skip the outer array element.

  You can append a number to break or continue to specify how many loop levels the signal should pierce.

• #102 2243c7e Thanks @copilot-swe-agent! - Sync tool optimisation — honour the sync flag in ToolMetadata

  When a tool declares { sync: true } in its .bridge metadata the engine
  now enforces and optimises it:

  1. Enforcement — if a sync-declared tool returns a Promise, both the
     runtime and compiled engines throw immediately.
  2. Core optimisation — callTool() skips timeout racing, the OTel span
     wrapper, and all promise handling for sync tools.
  3. Compiler optimisation — generated code uses a dedicated __callSync()
     helper at every call-site, avoiding await overhead entirely.
  4. Array-map fast path — when all per-element tools in an array map are
     sync, the compiled engine generates a dual-path: a synchronous .map()
     branch (no microtask ticks) with a runtime fallback to for…of + await
     for async tools.

  Benchmarks show up to ~50 % latency reduction for compiled array maps
  with sync tools (100 elements).

• #100 8e5b2e2 Thanks @aarne! - Add ToolMetadata — per-tool observability controls

  Tools can now attach a .bridge property to declare how the engine should
  instrument them, imported as ToolMetadata from @stackables/bridge.

  import type { ToolMetadata } from "@stackables/bridge";
  
  myTool.bridge = {
    trace: false, // skip OTel span for this tool
    log: {
      execution: "info", // log successful calls at info level
      errors: "error", // log failures at error level (default)
    },
  } satisfies ToolMetadata;

Patch Changes

• #103 fc6c619 Thanks @aarne! - Fix AOT/runtime parity for null element traversal, catch-null recovery, and non-array source handling

• Updated dependencies [fc6c619, 8e5b2e2]:

  • @stackables/bridge-stdlib@1.5.2
  • @stackables/bridge-types@1.1.0

@stackables/bridge-compiler@2.4.0

Minor Changes

• #104 b213e9f Thanks @copilot-swe-agent! - Multi-Level Control Flow (break N, continue N)

  When working with deeply nested arrays (e.g., mapping categories that contain lists of products), you may want an error deep inside the inner array to skip the outer array element.

  You can append a number to break or continue to specify how many loop levels the signal should pierce.

• #102 2243c7e Thanks @copilot-swe-agent! - Sync tool optimisation — honour the sync flag in ToolMetadata

  When a tool declares { sync: true } in its .bridge metadata the engine
  now enforces and optimises it:

  1. Enforcement — if a sync-declared tool returns a Promise, both the
     runtime and compiled engines throw immediately.
  2. Core optimisation — callTool() skips timeout racing, the OTel span
     wrapper, and all promise handling for sync tools.
  3. Compiler optimisation — generated code uses a dedicated __callSync()
     helper at every call-site, avoiding await overhead entirely.
  4. Array-map fast path — when all per-element tools in an array map are
     sync, the compiled engine generates a dual-path: a synchronous .map()
     branch (no microtask ticks) with a runtime fallback to for…of + await
     for async tools.

  Benchmarks show up to ~50 % latency reduction for compiled array maps
  with sync tools (100 elements).

Patch Changes

• #103 fc6c619 Thanks @aarne! - Fix AOT compiler to throw BridgeTimeoutError on tool timeout

  AOT-compiled bridges now throw BridgeTimeoutError (with the same name and
  message format as the runtime) when a tool exceeds toolTimeoutMs. Previously
  the generated code constructed a generic Error, causing a class mismatch when
  callers caught and inspected the error type.

• #103 fc6c619 Thanks @aarne! - Fix AOT/runtime parity for null element traversal, catch-null recovery, and non-array source handling

• Updated dependencies [b213e9f, fc6c619, fc6c619, 2243c7e, 8e5b2e2]:

  • @stackables/bridge-core@1.5.0
  • @stackables/bridge-stdlib@1.5.2

@stackables/bridge@2.2.0

Minor Changes

• #96 7384d3f Thanks @aarne! - Migrate wire shape from separate falsyFallback*/nullishFallback* properties to a unified fallbacks: WireFallback[] array, enabling mixed || and ?? chains in any order (e.g. A ?? B || C ?? D).

Patch Changes

• #94 93bbb94 Thanks @copilot-swe-agent! - Fix chained || literal fallback parsing so authored left-to-right short-circuiting is preserved after safe pulls (?.), and add regression coverage for mixed || + ?? chains.

• Updated dependencies [93bbb94, 7384d3f]:

  • @stackables/bridge-parser@1.3.0
  • @stackables/bridge-core@1.4.0
  • @stackables/bridge-graphql@1.1.4

@stackables/bridge@2.1.4

Patch Changes

• Updated dependencies [fc3d8ed]:
  • @stackables/bridge-parser@1.2.0
  • @stackables/bridge-core@1.3.0
  • @stackables/bridge-graphql@1.1.3

@stackables/bridge-types@1.0.1

Patch Changes

• 8e4ce59: Unintended tsconfig change broke package exports.