Skip to content

feat(deps): Update Minor updates#16

Open
renovate[bot] wants to merge 1 commit intomainfrom
renovate/minor-updates
Open

feat(deps): Update Minor updates#16
renovate[bot] wants to merge 1 commit intomainfrom
renovate/minor-updates

Conversation

@renovate
Copy link
Contributor

@renovate renovate bot commented Sep 30, 2025 •
edited
Loading

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Change Age Confidence
@effect/ai (source) 0.28.0 → 0.33.2 age confidence
@effect/ai-anthropic (source) 0.18.0 → 0.23.0 age confidence
@effect/ai-openai (source) 0.31.0 → 0.37.2 age confidence
@effect/cli (source) 0.70.0 → 0.73.2 age confidence
@effect/cluster (source) 0.49.0 → 0.56.4 age confidence
@effect/experimental (source) 0.55.0 → 0.58.0 age confidence
@effect/opentelemetry (source) 0.57.0 → 0.61.0 age confidence
@effect/platform (source) 0.91.1 → 0.94.5 age confidence
@effect/platform-browser (source) 0.71.0 → 0.74.0 age confidence
@effect/platform-bun (source) 0.80.0 → 0.87.1 age confidence
@effect/platform-node (source) 0.97.0 → 0.104.1 age confidence
@effect/platform-node-shared (source) 0.50.0 → 0.57.1 age confidence
@effect/printer (source) 0.45.0 → 0.47.0 age confidence
@effect/printer-ansi (source) 0.45.0 → 0.47.0 age confidence
@effect/rpc (source) 0.70.0 → 0.73.1 age confidence
@effect/sql (source) 0.45.0 → 0.49.0 age confidence
@effect/typeclass (source) 0.36.0 → 0.38.0 age confidence
@effect/workflow (source) 0.10.0 → 0.16.0 age confidence
@formatjs/intl-durationformat 0.7.4 → 0.10.1 age confidence
@paralleldrive/cuid2 3.1.0 → 3.3.0 age confidence
effect (source) 3.17.14 → 3.19.17 age confidence
type-fest 5.0.1 → 5.4.4 age confidence

Release Notes

Effect-TS/effect (@​effect/ai)

v0.33.2

Compare Source

Patch Changes

v0.33.1

Compare Source

Patch Changes

v0.33.0

Compare Source

Patch Changes

v0.32.1

Compare Source

Patch Changes

  • #​5685 fb53370 Thanks @​janglad! - Fix Response.Part, AllParts, StreamPart not inferring Schema properly if toolkit is WithHandler

  • Updated dependencies [7d28a90]:

    • effect@​3.19.3

v0.32.0

Compare Source

Patch Changes

v0.31.1

Compare Source

Patch Changes

v0.31.0

Compare Source

Minor Changes

  • #​5621 4c3bdfb Thanks @​IMax153! - Remove Either / EitherEncoded from tool call results.

    Specifically, the encoding of tool call results as an Either / EitherEncoded has been removed and is replaced by encoding the tool call success / failure directly into the result property.

    To allow type-safe discrimination between a tool call result which was a success vs. one that was a failure, an isFailure property has also been added to the "tool-result" part. If isFailure is true, then the tool call handler result was an error.

    import * as AnthropicClient from "@​effect/ai-anthropic/AnthropicClient"
import * as AnthropicLanguageModel from "@​effect/ai-anthropic/AnthropicLanguageModel"
import * as LanguageModel from "@​effect/ai/LanguageModel"
import * as Tool from "@​effect/ai/Tool"
import * as Toolkit from "@​effect/ai/Toolkit"
import * as NodeHttpClient from "@​effect/platform-node/NodeHttpClient"
import { Config, Effect, Layer, Schema, Stream } from "effect"

const Claude = AnthropicLanguageModel.model("claude-4-sonnet-20250514")

const MyTool = Tool.make("MyTool", {
  description: "An example of a tool with success and failure types",
  failureMode: "return", // Return errors in the response
  parameters: { bar: Schema.Number },
  success: Schema.Number,
  failure: Schema.Struct({ reason: Schema.Literal("reason-1", "reason-2") })
})

const MyToolkit = Toolkit.make(MyTool)

const MyToolkitLayer = MyToolkit.toLayer({
  MyTool: () => Effect.succeed(42)
})

const program = LanguageModel.streamText({
  prompt: "Tell me about the meaning of life",
  toolkit: MyToolkit
}).pipe(
  Stream.runForEach((part) => {
    if (part.type === "tool-result" && part.name === "MyTool") {
      // The `isFailure` property can be used to discriminate whether the result
      // of a tool call is a success or a failure
      if (part.isFailure) {
        part.result
        //   ^? { readonly reason: "reason-1" | "reason-2"; }
      } else {
        part.result
        //   ^? number
      }
    }
    return Effect.void
  }),
  Effect.provide(Claude)
)

const Anthropic = AnthropicClient.layerConfig({
  apiKey: Config.redacted("ANTHROPIC_API_KEY")
}).pipe(Layer.provide(NodeHttpClient.layerUndici))

program.pipe(Effect.provide([Anthropic, MyToolkitLayer]), Effect.runPromise)

v0.30.0

Compare Source

Minor Changes

  • #​5614 c63e658 Thanks @​IMax153! - Previously, tool call handler errors were always raised as an expected error in the Effect E channel at the point of execution of the tool call handler (i.e. when a generate* method is invoked on a LanguageModel).

    With this PR, the end user now has control over whether tool call handler errors should be raised as an Effect error, or returned by the SDK to allow, for example, sending that error information to another application.

Tool Call Specification

The Tool.make and Tool.providerDefined constructors now take an extra optional parameter called failureMode, which can be set to either "error" or "return".

import { Tool } from "@​effect/ai"
import { Schema } from "effect"

const MyTool = Tool.make("MyTool", {
  description: "My special tool",
  failureMode: "return" // "error" (default) or "return"
  parameters: {
    myParam: Schema.String
  },
  success: Schema.Struct({
    mySuccess: Schema.String
  }),
  failure: Schema.Struct({
    myFailure: Schema.String
  })
})

The semantics of failureMode are as follows:

  • If set to "error" (the default), errors that occur during tool call handler execution will be returned in the error channel of the calling effect
  • If set to "return", errors that occur during tool call handler execution will be captured and returned as part of the tool call result
Response - Tool Result Parts

The result field of a "tool-result" part of a large language model provider response is now represented as an Either.

  • If the result is a Left, the result will be the failure specified in the tool call specification
  • If the result is a Right, the result will be the success specified in the tool call specification

This is only relevant if the end user sets failureMode to "return". If set to "error" (the default), then the result property will always be a Right with the successful result of the tool call handler.

Similarly the encodedResult field of a "tool-result" part will be represented as an EitherEncoded, where:

  • { _tag: "Left", left: <failure> } represents a tool call handler failure
  • { _tag: "Right", right: <success> } represents a tool call handler success
Prompt - Tool Result Parts

The result field of a "tool-result" part of a prompt will now only accept an EitherEncoded as specified above.

Patch Changes
  • Updated dependencies [6ae2f5d]:
    • effect@​3.18.4

v0.29.1

Compare Source

Patch Changes

v0.29.0

Compare Source

Minor Changes
  • #​5302 f8b93ac Thanks @​timurrakhimzhan! - Added "oneOf" property for generateText and streamText "toolChoice" to be able to pick a subset of tools, which are going to be passed to LLM
Patch Changes

v0.28.4

Compare Source

Patch Changes

v0.28.3

Compare Source

Patch Changes

v0.28.2

Compare Source

Patch Changes

v0.28.1

Compare Source

Patch Changes
Effect-TS/effect (@​effect/ai-anthropic)

v0.23.0

Compare Source

Patch Changes

v0.22.0

Compare Source

Patch Changes

v0.21.1

Compare Source

Patch Changes

v0.21.0

Compare Source

Minor Changes

  • #​5621 4c3bdfb Thanks @​IMax153! - Remove Either / EitherEncoded from tool call results.

    Specifically, the encoding of tool call results as an Either / EitherEncoded has been removed and is replaced by encoding the tool call success / failure directly into the result property.

    To allow type-safe discrimination between a tool call result which was a success vs. one that was a failure, an isFailure property has also been added to the "tool-result" part. If isFailure is true, then the tool call handler result was an error.

    import * as AnthropicClient from "@&#8203;effect/ai-anthropic/AnthropicClient"
import * as AnthropicLanguageModel from "@&#8203;effect/ai-anthropic/AnthropicLanguageModel"
import * as LanguageModel from "@&#8203;effect/ai/LanguageModel"
import * as Tool from "@&#8203;effect/ai/Tool"
import * as Toolkit from "@&#8203;effect/ai/Toolkit"
import * as NodeHttpClient from "@&#8203;effect/platform-node/NodeHttpClient"
import { Config, Effect, Layer, Schema, Stream } from "effect"

const Claude = AnthropicLanguageModel.model("claude-4-sonnet-20250514")

const MyTool = Tool.make("MyTool", {
  description: "An example of a tool with success and failure types",
  failureMode: "return", // Return errors in the response
  parameters: { bar: Schema.Number },
  success: Schema.Number,
  failure: Schema.Struct({ reason: Schema.Literal("reason-1", "reason-2") })
})

const MyToolkit = Toolkit.make(MyTool)

const MyToolkitLayer = MyToolkit.toLayer({
  MyTool: () => Effect.succeed(42)
})

const program = LanguageModel.streamText({
  prompt: "Tell me about the meaning of life",
  toolkit: MyToolkit
}).pipe(
  Stream.runForEach((part) => {
    if (part.type === "tool-result" && part.name === "MyTool") {
      // The `isFailure` property can be used to discriminate whether the result
      // of a tool call is a success or a failure
      if (part.isFailure) {
        part.result
        //   ^? { readonly reason: "reason-1" | "reason-2"; }
      } else {
        part.result
        //   ^? number
      }
    }
    return Effect.void
  }),
  Effect.provide(Claude)
)

const Anthropic = AnthropicClient.layerConfig({
  apiKey: Config.redacted("ANTHROPIC_API_KEY")
}).pipe(Layer.provide(NodeHttpClient.layerUndici))

program.pipe(Effect.provide([Anthropic, MyToolkitLayer]), Effect.runPromise)
Patch Changes

v0.20.0

Compare Source

Minor Changes

  • #​5614 c63e658 Thanks @​IMax153! - Previously, tool call handler errors were always raised as an expected error in the Effect E channel at the point of execution of the tool call handler (i.e. when a generate* method is invoked on a LanguageModel).

    With this PR, the end user now has control over whether tool call handler errors should be raised as an Effect error, or returned by the SDK to allow, for example, sending that error information to another application.

Tool Call Specification

The Tool.make and Tool.providerDefined constructors now take an extra optional parameter called failureMode, which can be set to either "error" or "return".

import { Tool } from "@&#8203;effect/ai"
import { Schema } from "effect"

const MyTool = Tool.make("MyTool", {
  description: "My special tool",
  failureMode: "return" // "error" (default) or "return"
  parameters: {
    myParam: Schema.String
  },
  success: Schema.Struct({
    mySuccess: Schema.String
  }),
  failure: Schema.Struct({
    myFailure: Schema.String
  })
})

The semantics of failureMode are as follows:

  • If set to "error" (the default), errors that occur during tool call handler execution will be returned in the error channel of the calling effect
  • If set to "return", errors that occur during tool call handler execution will be captured and returned as part of the tool call result
Response - Tool Result Parts

The result field of a "tool-result" part of a large language model provider response is now represented as an Either.

  • If the result is a Left, the result will be the failure specified in the tool call specification
  • If the result is a Right, the result will be the success specified in the tool call specification

This is only relevant if the end user sets failureMode to "return". If set to "error" (the default), then the result property will always be a Right with the successful result of the tool call handler.

Similarly the encodedResult field of a "tool-result" part will be represented as an EitherEncoded, where:

  • { _tag: "Left", left: <failure> } represents a tool call handler failure
  • { _tag: "Right", right: <success> } represents a tool call handler success
Prompt - Tool Result Parts

The result field of a "tool-result" part of a prompt will now only accept an EitherEncoded as specified above.

Patch Changes

v0.19.2

Compare Source

Patch Changes

v0.19.1

Compare Source

Patch Changes

v0.19.0

Compare Source

Patch Changes

v0.18.2

Compare Source

Patch Changes

v0.18.1

Compare Source

Patch Changes
Effect-TS/effect (@​effect/ai-openai)

v0.37.2

Compare Source

Patch Changes

v0.37.1

Compare Source

Patch Changes

v0.37.0

Compare Source

Patch Changes

v0.36.0

Compare Source

Minor Changes
Patch Changes

v0.35.0

Compare Source

Patch Changes

v0.34.0

Compare Source

Minor Changes

  • #​5621 4c3bdfb Thanks @​IMax153! - Remove Either / EitherEncoded from tool call results.

    Specifically, the encoding of tool call results as an Either / EitherEncoded has been removed and is replaced by encoding the tool call success / failure directly into the result property.

    To allow type-safe discrimination between a tool call result which was a success vs. one that was a failure, an isFailure property has also been added to the "tool-result" part. If isFailure is true, then the tool call handler result was an error.

    import * as AnthropicClient from "@&#8203;effect/ai-anthropic/AnthropicClient"
import * as AnthropicLanguageModel from "@&#8203;effect/ai-anthropic/AnthropicLanguageModel"
import * as LanguageModel from "@&#8203;effect/ai/LanguageModel"
import * as Tool from "@&#8203;effect/ai/Tool"
import * as Toolkit from "@&#8203;effect/ai/Toolkit"
import * as NodeHttpClient from "@&#8203;effect/platform-node/NodeHttpClient"
import { Config, Effect, Layer, Schema, Stream } from "effect"

const Claude = AnthropicLanguageModel.model("claude-4-sonnet-20250514")

const MyTool = Tool.make("MyTool", {
  description: "An example of a tool with success and failure types",
  failureMode: "return", // Return errors in the response
  parameters: { bar: Schema.Number },
  success: Schema.Number,
  failure: Schema.Struct({ reason: Schema.Literal("reason-1", "reason-2") })
})

const MyToolkit = Toolkit.make(MyTool)

const MyToolkitLayer = MyToolkit.toLayer({
  MyTool: () => Effect.succeed(42)
})

const program = LanguageModel.streamText({
  prompt: "Tell me about the meaning of life",
  toolkit: MyToolkit
}).pipe(
  Stream.runForEach((part) => {
    if (part.type === "tool-result" && part.name === "MyTool") {
      // The `isFailure` property can be used to discriminate whether the result
      // of a tool call is a success or a failure
      if (part.isFailure) {
        part.result
        //   ^? { readonly reason: "reason-1" | "reason-2"; }
      } else {
        part.result
        //   ^? number
      }
    }
    return Effect.void
  }),
  Effect.provide(Claude)
)

const Anthropic = AnthropicClient.layerConfig({
  apiKey: Config.redacted("ANTHROPIC_API_KEY")
}).pipe(Layer.provide(NodeHttpClient.layerUndici))

program.pipe(Effect.provide([Anthropic, MyToolkitLayer]), Effect.runPromise)
Patch Changes

v0.33.0

Compare Source

Minor Changes

  • #​5614 c63e658 Thanks @​IMax153! - Previously, tool call handler errors were always raised as an expected error in the Effect E channel at the point of execution of the tool call handler (i.e. when a generate* method is invoked on a LanguageModel).

    With this PR, the end user now has control over whether tool call handler errors should be raised as an Effect error, or returned by the SDK to allow, for example, sending that error information to another application.

Tool Call Specification

The Tool.make and Tool.providerDefined constructors now take an extra optional parameter called failureMode, which can be set to either "error" or "return".

import { Tool } from "@&#8203;effect/ai"
import { Schema } from "effect"

const MyTool = Tool.make("MyTool", {
  description: "My special tool",
  failureMode: "return" // "error" (default) or "return"
  parameters: {
    myParam: Schema.String
  },
  success: Schema.Struct({
    mySuccess: Schema.String
  }),
  failure: Schema.Struct({
    myFailure: Schema.String
  })
})

The semantics of failureMode are as follows:

  • If set to "error" (the default), errors that occur during tool call handler execution will be returned in the error channel of the calling effect
  • If set to "return", errors that occur during tool call handler execution will be captured and returned as part of the tool call result
Response - Tool Result Parts

The result field of a "tool-result" part of a large language model provider response is now represented as an Either.

  • If the result is a Left, the result will be the failure specified in the tool call specification
  • If the result is a Right, the result will be the success specified in the tool call specification

This is only relevant if the end user sets failureMode to "return". If set to "error" (the default), then the result property will always be a Right with the successful result of the tool call handler.

Similarly the encodedResult field of a "tool-result" part will be represented as an EitherEncoded, where:

  • { _tag: "Left", left: <failure> } represents a tool call handler failure
  • { _tag: "Right", right: <success> } represents a tool call handler success
Prompt - Tool Result Parts

The result field of a "tool-result" part of a prompt will now only accept an EitherEncoded as specified above.

Patch Changes

v0.32.1

Compare Source

Patch Changes

v0.32.0

Compare Source

Patch Changes

v0.31.1

Compare Source

Patch Changes
Effect-TS/effect (@​effect/cli)

v0.73.2

Compare Source

Patch Changes

v0.73.1

Compare Source

Patch Changes

  • #​5983 0d1a44f Thanks @​cevr! - Allow options to appear after positional arguments

    Previously, @effect/cli required all options to appear before positional arguments. For example, cmd --force staging worked but cmd staging --force failed with "Received unknown argument".

    This change updates the option parsing logic to scan through all arguments to find options, regardless of their position relative to positional arguments. This aligns with the behavior of most CLI tools (git, npm, docker, etc.) which allow options anywhere in the command.

    Before:

    myapp deploy --force staging  # worked
myapp deploy staging --force  # failed: "Received unknown argument: '--force'"

    After:

    myapp deploy --force staging  # works
myapp deploy staging --force  # works

  • Updated dependencies [7e925ea, 118e7a4, d7e75d6, 4860d1e]:

v0.73.0

Compare Source

Patch Changes

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate bot force-pushed the renovate/minor-updates branch 9 times, most recently from 7750517 to e34dbb4 Compare October 7, 2025 00:52
@renovate renovate bot force-pushed the renovate/minor-updates branch 3 times, most recently from 8312c41 to 3e77cff Compare October 14, 2025 15:10
@renovate renovate bot force-pushed the renovate/minor-updates branch 5 times, most recently from 5d9eba9 to 63ebe03 Compare October 21, 2025 16:50
@renovate renovate bot force-pushed the renovate/minor-updates branch from 63ebe03 to 303aa01 Compare October 24, 2025 14:44
@renovate renovate bot force-pushed the renovate/minor-updates branch 10 times, most recently from 4ab32ac to 9f305e4 Compare November 10, 2025 01:33
@renovate renovate bot force-pushed the renovate/minor-updates branch 6 times, most recently from 1655e75 to bbafe26 Compare December 17, 2025 06:46
@renovate renovate bot force-pushed the renovate/minor-updates branch 3 times, most recently from a09a362 to 3f4d3df Compare December 23, 2025 18:02
@renovate renovate bot force-pushed the renovate/minor-updates branch 2 times, most recently from 379a896 to d084ea0 Compare January 1, 2026 07:32
@renovate renovate bot force-pushed the renovate/minor-updates branch 5 times, most recently from 94304b1 to c00d95c Compare January 6, 2026 17:31
@renovate renovate bot force-pushed the renovate/minor-updates branch 3 times, most recently from c9c6ce8 to 0b2689c Compare January 15, 2026 17:46
@renovate renovate bot force-pushed the renovate/minor-updates branch 3 times, most recently from 73ff256 to 73571c3 Compare January 27, 2026 19:00
@renovate renovate bot force-pushed the renovate/minor-updates branch 4 times, most recently from c908172 to ca52c7a Compare February 5, 2026 05:49
@renovate renovate bot force-pushed the renovate/minor-updates branch 2 times, most recently from ffcdebb to 185515c Compare February 9, 2026 02:32
@renovate renovate bot force-pushed the renovate/minor-updates branch from 185515c to 45258c1 Compare February 14, 2026 08:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

deps renovate

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants