Dependency Dashboard

[renovate]

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.
View this repository on the Mend.io Web Portal.

Abandoned Dependencies

The following dependencies have not received updates for an extended period and may be unmaintained.

View abandoned dependencies (2)

[!NOTE]
Packages are marked as abandoned when they exceed the abandonmentThreshold since their last release. Unlike deprecated packages with official notices, abandonment is detected by release inactivity.

Datasource	Package	Last Updated
npm	class-variance-authority	2024-11-26
npm	clsx	2024-04-23

Awaiting Schedule

The following updates are awaiting their schedule. To get an update now, click on a checkbox below.

• deps: Lock file maintenance

Pending Status Checks

The following updates await pending status checks. To force their creation now, click on a checkbox below.

• deps: Update docker/dockerfile:1 Docker digest to ecfaec9
• deps: Update mcr.microsoft.com/dotnet/runtime-deps:10.0 Docker digest to 851e6e0

PR Closed (Blocked)

The following updates are blocked by an existing closed PR. To recreate the PR, click on a checkbox below.

• deps: Update ancplua-sdk to 2.2.42 (ANcpLua.Roslyn.Utilities, ANcpLua.Roslyn.Utilities.Testing)

Detected Dependencies

docker-compose (1)

eng/compose.yaml

dockerfile (1)

services/qyl.collector/Dockerfile (4)

• docker/dockerfile 1@sha256:87999aa3d42bdc6bea60565083ee17e86d1f3339802f543c0d03998580f9cb89 → [Updates: 1]
• node 24-slim@sha256:3638d9a6fe4030bd716be989438248074489337ba3275657f93595428be4fc03
• mcr.microsoft.com/dotnet/sdk 10.0.400-noble-aot@sha256:74edbceabfc6d1a7e4a5764be034fd744a07f60d26703232e74f6a5edc04e8ba
• mcr.microsoft.com/dotnet/runtime-deps 10.0@sha256:894098eafc82e5fa02ba9f2b71d426dc78252876b9e914caae77ed95cfce185a → [Updates: 10.0]

github-actions (3)

.github/workflows/ci.yml (18)

• actions/checkout v7@3d3c42e5aac5ba805825da76410c181273ba90b1
• actions/checkout v7@3d3c42e5aac5ba805825da76410c181273ba90b1
• actions/setup-dotnet v6@a98b56852c35b8e3190ac28c8c2271da59106c68
• actions/checkout v7@3d3c42e5aac5ba805825da76410c181273ba90b1
• actions/setup-dotnet v6@a98b56852c35b8e3190ac28c8c2271da59106c68
• actions/setup-node v7@820762786026740c76f36085b0efc47a31fe5020
• actions/checkout v7@3d3c42e5aac5ba805825da76410c181273ba90b1
• actions/setup-dotnet v6@a98b56852c35b8e3190ac28c8c2271da59106c68
• actions/checkout v7@3d3c42e5aac5ba805825da76410c181273ba90b1
• actions/setup-dotnet v6@a98b56852c35b8e3190ac28c8c2271da59106c68
• actions/setup-node v7@820762786026740c76f36085b0efc47a31fe5020
• actions/upload-artifact v7@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a
• actions/checkout v7@3d3c42e5aac5ba805825da76410c181273ba90b1
• actions/setup-dotnet v6@a98b56852c35b8e3190ac28c8c2271da59106c68
• actions/setup-node v7@820762786026740c76f36085b0efc47a31fe5020
• actions/checkout v7@3d3c42e5aac5ba805825da76410c181273ba90b1
• actions/setup-dotnet v6@a98b56852c35b8e3190ac28c8c2271da59106c68
• actions/setup-node v7@820762786026740c76f36085b0efc47a31fe5020

.github/workflows/links.yml (2)

• actions/checkout v7@3d3c42e5aac5ba805825da76410c181273ba90b1
• lycheeverse/lychee-action v2.9.0@e7477775783ea5526144ba13e8db5eec57747ce8

.github/workflows/nuget-publish.yml (14)

• actions/checkout v7@3d3c42e5aac5ba805825da76410c181273ba90b1
• actions/checkout v7@3d3c42e5aac5ba805825da76410c181273ba90b1
• actions/setup-dotnet v6@a98b56852c35b8e3190ac28c8c2271da59106c68
• actions/setup-node v7@820762786026740c76f36085b0efc47a31fe5020
• actions/upload-artifact v7@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a
• actions/checkout v7@3d3c42e5aac5ba805825da76410c181273ba90b1
• actions/setup-dotnet v6@a98b56852c35b8e3190ac28c8c2271da59106c68
• actions/setup-node v7@820762786026740c76f36085b0efc47a31fe5020
• actions/download-artifact v8@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c
• actions/upload-artifact v7@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a
• actions/checkout v7@3d3c42e5aac5ba805825da76410c181273ba90b1
• actions/download-artifact v8@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c
• actions/setup-dotnet v6@a98b56852c35b8e3190ac28c8c2271da59106c68
• NuGet/login v1@8d196754b4036150537f80ac539e15c2f1028841

npm (1)

services/qyl.dashboard/package.json (26)

• @ancplua/qyl-api-schema 7.1.0
• @base-ui/react ^1.4.1
• @tanstack/react-query ^5.99.2
• @tanstack/react-virtual ^3.13.24
• ajv 8.20.0
• class-variance-authority ^0.7.1
• clsx ^2.1.1
• lucide-react ^1.8.0
• react ^19.2.5
• react-dom ^19.2.5
• react-router ^8.3.0
• sonner ^2.0.7
• tailwind-merge ^3.5.0
• @playwright/test 1.62.1
• @tailwindcss/vite 4.3.3
• @types/react 19.2.18
• @types/react-dom 19.2.4
• @vitejs/plugin-react 6.0.5
• @vitest/coverage-v8 4.1.10
• jsdom 30.0.1
• oxlint 1.78.0
• tailwindcss 4.3.3
• typescript 7.0.2
• vite 8.2.1
• vitest 4.1.10
• node ^22.22.2 || ^24.15.0 || >=26.0.0

nuget (16)

Directory.Packages.props

eng/build/build.csproj

eng/tools/CollectorAotSmoke/CollectorAotSmoke.csproj

eng/tools/QylSdkConformance/QylSdkConformance.csproj

eng/tools/SdkVersionAnalyzer/SdkVersionAnalyzer.csproj

global.json (6)

• dotnet-sdk 10.0.400
• ANcpLua.NET.Sdk 3.4.45
• ANcpLua.NET.Sdk.Web 3.4.45
• ANcpLua.NET.Sdk.Test 3.4.45
• ANcpLua.Roslyn.Utilities.Testing 2.2.39 → [Updates: 2.2.42]
• ANcpLua.Roslyn.Utilities 2.2.39 → [Updates: 2.2.42]

internal/qyl.collector.storage.generators/qyl.collector.storage.generators.csproj (1)

• Microsoft.CodeAnalysis.CSharp 5.6.0

internal/qyl.instrumentation.generators/qyl.instrumentation.generators.csproj (1)

• Microsoft.CodeAnalysis.CSharp 5.6.0

internal/qyl.instrumentation/qyl.instrumentation.csproj

packages/Directory.Build.props

packages/Qyl.Cli/Qyl.Cli.csproj

packages/Qyl.Run.Workload/Qyl.Run.Workload.csproj

services/qyl.collector/qyl.collector.csproj

tests/Qyl.Cli.Tests/Qyl.Cli.Tests.csproj

tests/Qyl.Collector.Tests/Qyl.Collector.Tests.csproj

tests/Qyl.Sdk.Conformance/Qyl.Sdk.Conformance.csproj

nvm (1)

.nvmrc (1)

• node 24

renovate-config (1)

renovate.json

---

• Check this box to trigger a request for Renovate to run again on this repository

[coderabbitai]

🔗 Related PRs

#3 - fix: resolve NU1506 duplicate package errors and update SDK to 1.6.29 [merged]
#186 - ci(auto-merge): consume reusable workflow + keep Governance tier local [merged]
#194 - chore(deps-bot): remove Dependabot, make Renovate canonical [merged]
#240 - deps: bump ANcpLua.Agents 0.6 → 1.4.1 + trailing pins [merged]
#259 - ci: allow renovate Claude reviews and pin bot automerge [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[coderabbitai]

Coding Plan

Summary

• Lock file maintenance is an automated Renovate action—no code changes required from developers
• The checked checkbox triggers immediate execution; Renovate handles PR creation
• Manual fallback involves running npm install in 7 directories if automation fails
• Missing packageManager declarations create npm version drift risk across CI environments and developer machines

Implementation Steps

Phase 1: Automated Lock File Maintenance (Renovate-Driven)

The checked checkbox [x] deps: Lock file maintenance instructs Renovate to unschedule the pending maintenance and execute immediately. No manual implementation is required unless Renovate fails.

Task 1: Verify Renovate Execution

Confirm that Renovate creates the renovate/lock-file-maintenance branch and opens a PR.

• Monitor for PR creation on branch renovate/lock-file-maintenance
• Renovate will regenerate lock files in all 7 locations:
  • services/qyl.dashboard/package-lock.json
  • packages/qyl-client/package-lock.json
  • core/specs/package-lock.json
  • core/specs/emitters/csharp/package-lock.json
  • core/specs/emitters/duckdb/package-lock.json
  • core/specs/emitters/ts-types/package-lock.json
  • core/specs/emitters/qyl-semconv-lint/package-lock.json
• Lock file maintenance does NOT bump pinned versions—only transitive resolutions change

Task 2: CI Validation

Ensure the generated PR passes all CI checks before merge.

• Full test suite must pass—transitive bumps can introduce subtle breakage
• Pay attention to TypeSpec emitter packages under core/specs/emitters/; these have peer dependency constraints on @typespec/compiler ^1.12.0-dev
• Dashboard (qyl.dashboard) has Playwright and Vitest; watch for flaky tests from dependency drift

🤖 Prompt for AI agents

This phase is fully Renovate-driven; no code is generated by a coding agent. The
goal is to verify that Renovate correctly triggers and completes lock file
maintenance across all 7 packages.

- No code changes are required from developers in this phase
- Confirm that Renovate creates the `renovate/lock-file-maintenance` branch and
opens a PR targeting the correct base branch
- Validate that the PR includes regenerated `package-lock.json` files at all 7
paths:
  - `services/qyl.dashboard/package-lock.json`
  - `packages/qyl-client/package-lock.json`
  - `core/specs/package-lock.json`
  - `core/specs/emitters/csharp/package-lock.json`
  - `core/specs/emitters/duckdb/package-lock.json`
  - `core/specs/emitters/ts-types/package-lock.json`
  - `core/specs/emitters/qyl-semconv-lint/package-lock.json`
- Confirm that no `package.json` dependency versions are altered—only transitive
resolutions in the lock files should change
- Verify CI passes on the Renovate PR before merging; flag failures in TypeSpec
emitter packages (peer constraint `@typespec/compiler ^1.12.0-dev`) and in
`qyl.dashboard` (Playwright/Vitest) as high-priority—these are the most likely
breakage points from transitive drift

Phase 2: Manual Fallback (If Renovate Fails)

Only execute if Renovate does not create the maintenance PR within expected timeframe.

Task 1: Regenerate Lock Files Manually

Run npm install in each package directory to regenerate lock files.

• Use a consistent npm version (npm 10+ recommended for lockfile v3 compatibility)
• Execute in order (emitters before core/specs if local file: dependencies require it):

  core/specs/emitters/csharp/
  core/specs/emitters/duckdb/
  core/specs/emitters/ts-types/
  core/specs/emitters/qyl-semconv-lint/
  core/specs/
  packages/qyl-client/
  services/qyl.dashboard/
  

• Commit all 7 lock files in a single commit with message deps: Lock file maintenance

Task 2: Add packageManager Field (Recommended Follow-up)

Address npm version drift risk by pinning the package manager.

• Consider adding "packageManager": "npm@10.x.x" to each package.json, or
• Add a root-level .npmrc or tooling config if standardizing across packages
• This is out of scope for this ticket but flagged as technical debt

🤖 Prompt for AI agents

This phase is a manual fallback executed only if Renovate fails to produce the
maintenance PR. The goal is to reproduce what Renovate would have done:
regenerate all 7 `package-lock.json` files to their latest allowed transitive
resolutions.

- Use npm 10+ to ensure lockfile v3 format compatibility; using a mismatched npm
version will corrupt the lockfile format and create CI/developer machine drift
- Run `npm install` (not `npm ci`) in each package directory in the following
order to respect any local `file:` dependency edges:
  1. `core/specs/emitters/csharp/`
  2. `core/specs/emitters/duckdb/`
  3. `core/specs/emitters/ts-types/`
  4. `core/specs/emitters/qyl-semconv-lint/`
  5. `core/specs/`
  6. `packages/qyl-client/`
  7. `services/qyl.dashboard/`
- Do NOT modify any `package.json` files—only lock files should change
- Stage all 7 regenerated `package-lock.json` files and commit together with the
message: `deps: Lock file maintenance`
- The `packageManager` field addition is out of scope for this ticket; flag it
as technical debt but do not implement it here

Research

This repository contains 7 independent npm packages without workspace configuration. Each maintains its own package-lock.json (npm, lockfile v3). No packageManager field is declared anywhere—npm version is implicit. Renovate configuration delegates entirely to the external preset at github>ANcpLua/renovate-config, meaning lock file maintenance schedule and behavior are not locally visible or auditable.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

This phase is fully Renovate-driven; no code is generated by a coding agent. The
goal is to verify that Renovate correctly triggers and completes lock file
maintenance across all 7 packages.

- No code changes are required from developers in this phase
- Confirm that Renovate creates the `renovate/lock-file-maintenance` branch and
opens a PR targeting the correct base branch
- Validate that the PR includes regenerated `package-lock.json` files at all 7
paths:
  - `services/qyl.dashboard/package-lock.json`
  - `packages/qyl-client/package-lock.json`
  - `core/specs/package-lock.json`
  - `core/specs/emitters/csharp/package-lock.json`
  - `core/specs/emitters/duckdb/package-lock.json`
  - `core/specs/emitters/ts-types/package-lock.json`
  - `core/specs/emitters/qyl-semconv-lint/package-lock.json`
- Confirm that no `package.json` dependency versions are altered—only transitive
resolutions in the lock files should change
- Verify CI passes on the Renovate PR before merging; flag failures in TypeSpec
emitter packages (peer constraint `@typespec/compiler ^1.12.0-dev`) and in
`qyl.dashboard` (Playwright/Vitest) as high-priority—these are the most likely
breakage points from transitive drift
===============================================================================

Task: 2

This phase is a manual fallback executed only if Renovate fails to produce the
maintenance PR. The goal is to reproduce what Renovate would have done:
regenerate all 7 `package-lock.json` files to their latest allowed transitive
resolutions.

- Use npm 10+ to ensure lockfile v3 format compatibility; using a mismatched npm
version will corrupt the lockfile format and create CI/developer machine drift
- Run `npm install` (not `npm ci`) in each package directory in the following
order to respect any local `file:` dependency edges:
  1. `core/specs/emitters/csharp/`
  2. `core/specs/emitters/duckdb/`
  3. `core/specs/emitters/ts-types/`
  4. `core/specs/emitters/qyl-semconv-lint/`
  5. `core/specs/`
  6. `packages/qyl-client/`
  7. `services/qyl.dashboard/`
- Do NOT modify any `package.json` files—only lock files should change
- Stage all 7 regenerated `package-lock.json` files and commit together with the
message: `deps: Lock file maintenance`
- The `packageManager` field addition is out of scope for this ticket; flag it
as technical debt but do not implement it here

💡 Iterate on the plan with: @coderabbitai <feedback>

Example Feedback
- @coderabbitai You can skip phase 3. Add a simple unit test case for phase 2.
- @coderabbitai For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!

[coderabbitai]

I've updated the plan above based on your feedback. Ready to proceed when you are!