[Aloento]

Brings every direct dependency to its latest release, major ranges included. The majors this project already runs on (React 19, Vite 8, Tailwind 4, ESLint 10) had no newer release, so all twelve bumps are minor or patch updates.

pnpm lint and pnpm build pass and a frozen-lockfile install is clean. The built dashboard was loaded in Edge next to a bundle from the previous dependency set: same render, no page errors, and the service worker registers and takes control in both.

Supersedes the open Dependabot PRs #416, #425, #426, #427 and #428.

[ecosquad-autoreview]

Summary

Dependency bump PR: 12 direct dependency updates in package.json plus the corresponding pnpm-lock.yaml regeneration. I verified every bump against the diff and confirmed all are minor or patch releases (no major changes), consistent with the PR description and with the project already running on React 19 / Vite 8 / Tailwind 4 / ESLint 10. package.json specifiers and the lockfile importers block are in agreement, so there is no drift between the manifest and the lock.

I could not run pnpm install, pnpm lint, or pnpm build in this environment, so I could not independently confirm the author's stated verification (frozen-lockfile install, lint, build, and the Edge render/service-worker check). CI checks (Analyze (javascript-typescript), Analyze (actions), check) were still in_progress at review time; GitGuardian Security Checks passed.

Findings

Warning — verify lockfile structure

File: pnpm-lock.yaml
The lock content I read contains two complete top-level documents: a first block with lockfileVersion: '9.0' + importers (holding only the packageManagerDependencies for pnpm and the @pnpm/exe.* platform binaries) and then a --- separator followed by a second lockfileVersion: '9.0' with its own settings, importers, packages, and snapshots (the actual project dependency tree). A standard pnpm v9 lockfile is a single document. The duplicated importers/packages structure can indicate that the previous lockfile content was not fully replaced during the bump (i.e. stale content concatenated with the regenerated section).
Why it matters: A malformed or partially-written lockfile can cause pnpm install --frozen-lockfile to fail in CI or to resolve differently than intended, even if a local install appeared to work.
Concrete fix: Confirm the committed pnpm-lock.yaml is a single well-formed document. Re-run pnpm install --frozen-lockfile from a clean checkout (CI is a good proxy) and ensure it is green; if the duplication is real, regenerate the lockfile with rm pnpm-lock.yaml && pnpm install and re-commit. If the first section is an intentional pnpm package-manager artifact, that's fine, but it should be confirmed rather than assumed.

Suggestion — bump count in description

File: PR description
The description says "all eleven bumps are minor or patch," but I count 12 changed direct dependencies: @fluentui/react-components, @telekom/scale-components, ahooks, @tailwindcss/postcss, @types/node, @vitejs/plugin-react, eslint, globals, postcss, tailwindcss, typescript-eslint, vite. This is cosmetic, but the count should be corrected for an accurate changelog.

Suggestion — note on @telekom/scale-components

File: package.json
@telekom/scale-components and @telekom/scale-components-react are pinned to pre-release 3.0.0-beta.162. Bumping a beta is low risk here (the -react package was already at 162, so this aligns the two), but be aware beta versions are not semver-stable — worth a quick sanity check that the 161→162 delta didn't change any component API the dashboard imports.

Verdict

No correctness, security, or build-blocking issue is evident from the code that I can inspect, and the change is a mechanical, low-risk dependency bump whose author has performed runtime verification. The only substantive item is the unusual duplicated lockfile structure, which I flag for confirmation rather than as a proven defect. Approve, with the request to confirm the pnpm-lock.yaml is a single clean document (and that the check CI job is green) before the merge button is pressed.

[ecosquad-autoreview]

Summary

Dependency upgrade PR: 12 direct dependencies in package.json bumped to their latest releases, plus the matching pnpm-lock.yaml update. All bumps are minor/patch (verified against the PR description — no major-range changes; React 19, Vite 8, Tailwind 4, ESLint 10 are untouched). I spot-checked the lockfile: the importer specifiers and resolved versions in pnpm-lock.yaml match package.json exactly (@fluentui/react-components 9.75.2, @telekom/scale-components 3.0.0-beta.162, ahooks 3.11.0, tailwindcss 4.3.5, vite 8.3.8, @vitejs/plugin-react 6.3.0, eslint 10.14.0, typescript-eslint 8.72.2, postcss 8.5.32, globals 17.14.0, @types/node 26.6.6), and @telekom/scale-components and @telekom/scale-components-react remain pinned to the same beta, which is correct for those fixed versions. No code changes to review.

Findings

Warning — CI is not green; build/lint results are unverified

The head commit's checks show check as in_progress and both CodeQL "Analyze" jobs still queued; only the GitGuardian secret scan passed. This environment cannot run pnpm install --frozen-lockfile, pnpm lint or pnpm build, so the PR description's claim that these pass is unverified. Do not merge until the check job completes successfully. If it fails, the usual suspects for a bulk bump are a changed transitive dependency or the Vite/@vitejs/plugin-react 6.3.0 combination.

Suggestion — lockfile now contains two YAML documents

pnpm-lock.yaml starts with a new first document (lockfileVersion: '9.0', packageManagerDependencies: {pnpm: 12.5.1}, pnpm@12.5.1 plus 14 @pnpm/exe.* platform binaries, pnpm-lock.yaml lines 1–~70) separated from the real lockfile by a ---. This looks like a new pnpm 12 feature for pinning the package manager itself, and the two documents are internally consistent (pnpm 12.5.1 matches the packageManager field in package.json). Flagging it only because: (1) it is unusual and not mentioned in the PR description — worth a one-line note for future maintainers, and (2) any tooling that parses the lockfile as a single YAML document (e.g. Renovate's older parsers, custom audit scripts) may see the wrong document. No action required beyond awareness; if the first document was not produced deliberately by pnpm install, it should be regenerated.

Suggestion — consider whether @telekom/scale-components should also be unpinned

package.json line 14 pins @telekom/scale-components to an exact beta (3.0.0-beta.162) rather than a range. Since both Telekom packages moved to beta.162 together and this PR's stated goal is "every direct dependency to its latest release," this is consistent — but the exact pin means the next beta release won't be picked up automatically. Fine as-is; just noting it.

Verdict

Approve — the dependency changes are minor/patch-only, the lockfile is consistent with package.json, and no application code is affected. The only condition is that the still-running CI check job (lint + build) passes before merging; it was in progress at review time.