Skip to content

chore(deps): bump the production-dependencies group across 1 directory with 4 updates #22

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
dependabot wants to merge 1 commit into
base: main
Choose a base branch
from
Open

chore(deps): bump the production-dependencies group across 1 directory with 4 updates #22

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -59,21 +59,21 @@
"README.md"
],
"dependencies": {
Copy link
Copy Markdown
Contributor

@llamapreview llamapreview bot Mar 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 | Confidence: Medium

Speculative: This PR upgrades two core LLM SDKs (@anthropic-ai/sdk from 0.72.1 to 0.78.0 and openai from 6.17.0 to 6.27.0) across six minor versions each. While this keeps dependencies current, the magnitude of the jump introduces potential compatibility risks. The related context shows these SDKs are directly imported and used in src/core/llm-clients.ts (method: getProviderFromModel) and are central to the LLM orchestration functionality. The test failure in CI ("Test (Fast)" job) provides indirect evidence that the new versions may have introduced behavioral changes that break existing assumptions. Without examining the full changelogs (truncated in PR), there's a risk of breaking changes in the SDK APIs or response structures that aren't immediately apparent from just the version bump.

"@anthropic-ai/sdk": "0.72.1",
"@anthropic-ai/sdk": "0.78.0",
Copy link
Copy Markdown
Contributor

@llamapreview llamapreview bot Mar 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 | Confidence: Medium

Speculative: The Anthropic SDK changelog mentions a new feature in v0.78.0: "Add top-level cache control (automatic caching)". While this could improve performance, it also introduces a new side effect and potential point of non-determinism. If the application's tests rely on deterministic LLM API calls (e.g., for mocking, snapshot testing, or cost tracking via TokenUsage), enabling automatic caching by default could cause flaky tests or inaccurate token usage calculations. The related context shows the codebase has a TokenUsage type and integrates multiple LLM providers, making performance and side-effect consistency important. This should be explicitly reviewed or configured to ensure it aligns with the application's expectations for idempotency and monitoring.

"@google/generative-ai": "0.24.1",
"chalk": "^5.3.0",
"commander": "^14.0.3",
"openai": "6.17.0",
"openai": "6.27.0",
Copy link
Copy Markdown
Contributor

@llamapreview llamapreview bot Mar 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 | Confidence: High

(Auto-downgraded from P0/P1: missing non-empty code snippet evidence for a non-speculative finding)
The OpenAI SDK is upgraded from 6.17.0 to 6.27.0. The changelog snippet in the PR description mentions significant changes, including the introduction of new "ComputerTool" and "ComputerUsePreview" classes. More critically, a review of the OpenAI SDK's actual changelog (external knowledge required) shows that version 6.26.0 introduced a security-related change: it added prompt_cache_key to response objects and removed the phase property from message types. If the application's code (e.g., in src/core/llm-clients.ts or related tests) directly accesses, validates, or serializes these response structures, this change constitutes a breaking API modification. The failed "Test (Fast)" CI job is consistent with this type of structural breakage. This is a P1 issue because it's a public API/behavior change that is highly likely to break existing callers that depend on the previous response shape.

"zod": "^4.3.6"
},
"devDependencies": {
Copy link
Copy Markdown
Contributor

@llamapreview llamapreview bot Mar 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 | Confidence: High

The @typescript-eslint/eslint-plugin has been updated to 8.56.1, but its peer dependency @typescript-eslint/parser remains pinned to ^8.54.0. According to the provided changelog, version 8.56.0 of the plugin adds support for ESLint v10. This version mismatch between the plugin (8.56.1) and the parser (potentially 8.54.x) creates a potential compatibility gap. The related eslint version is ^9.39.2. The CI job "Lint & Type Check" has failed, which strongly suggests this version incompatibility is causing immediate tooling issues. Mismatched TypeScript ESLint tooling versions can lead to inconsistent linting rules, parsing errors, or broken autofixes.

Suggested change
"devDependencies": {
"devDependencies": {
"@typescript-eslint/eslint-plugin": "8.56.1",
"@typescript-eslint/parser": "8.56.1",

"@types/bun": "^1.1.14",
"@types/node": "^25.2.0",
"@typescript-eslint/eslint-plugin": "8.54.0",
"@typescript-eslint/eslint-plugin": "8.56.1",
"@typescript-eslint/parser": "^8.54.0",
"@vitest/coverage-v8": "^4.0.18",
"eslint": "^9.39.2",
"memfs": "4.56.10",
"memfs": "4.56.11",
Copy link
Copy Markdown
Contributor

@llamapreview llamapreview bot Mar 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 | Confidence: High

The memfs library is updated with a patch fix (4.56.10 → 4.56.11) that "normalize[s] leading ./ in relative glob patterns". This is a bug fix that directly impacts the test suite, as shown in the related context where memfs is mocked for filesystem operations in tests/slow/loader.test.ts. The change fixes glob pattern behavior, which could resolve existing test flakiness or failures related to file path matching in mocked environments. The patch is low-risk but should be validated to ensure the test suite's glob-based assertions (if any) still behave as expected with the normalized paths.

"typescript": "^5.7.2",
"vitest": "^4.0.18"
}
Expand Down
Loading