chore(deps): upgrade project dependencies to latest versions

[Sourav-kashyap]

Description

This issue tracks upgrading all project dependencies to their latest stable versions.

Changes

• Updated all dependencies and devDependencies to latest versions
• Resolved version conflicts and peer dependency issues
• Fixed breaking changes introduced by major version upgrades

Checklist:

• Performed a self-review of my own code
• npm test passes on your machine

[rohit-sourcefuse]

Unpinned action version — supply chain risk

The Trivy action is changed from a pinned version tag (@0.28.0) to @master. Using a mutable ref like master means any future commit pushed to the upstream aquasecurity/trivy-action repository is automatically pulled into your CI without any review, which is a well-known supply chain attack vector.

I'd suggest pinning back to a specific release tag or a full commit SHA:

- name: Run Trivy vulnerability scanner in repo mode
  uses: aquasecurity/trivy-action@0.31.0
  with:
    scan-type: 'fs'
    scan-ref: '${{ github.workspace }}'
    trivy-config: '${{ github.workspace }}/trivy.yml'

Rationale: a vulnerability scanner workflow is especially sensitive — it has access to your source tree and runs on every PR. Pinning to an immutable ref (tag or SHA) ensures you control exactly what code executes.

[Sourav-kashyap]

resolved

[rohit-sourcefuse]

actions/checkout@v3 is still present while upgrading other dependencies

This PR upgrades a broad range of dependencies to latest versions, but both trivy.yaml and main.yaml still reference actions/checkout@v3 and actions/setup-node@v3. actions/checkout@v4 has been out since September 2023 and addresses security fixes including the GHSA-2j82-pqph-pj2w advisory.

Suggestion — bump checkout and setup-node while you're touching this file:

- uses: actions/checkout@v4

This keeps the dependency upgrade story consistent across the whole PR.

[Sourav-kashyap]

resolved

[rohit-sourcefuse]

@types/node is still pinned at ^16.18.119 while testing against Node 20, 22, and 24

The CI matrix tests on Node.js 20, 22, and 24 (added in this PR), but the TypeScript type definitions are still based on Node 16. This creates a mismatch: type definitions for APIs added or changed in Node 18–24 (e.g. crypto.randomUUID, fetch, updated Buffer types) are absent, which can cause false-positive TypeScript errors or, worse, silently allow incorrect usage of newer APIs.

jsdom@29 also transitively requires Node ≥ 20 (^20.19.0 || ^22.12.0 || >=24.0.0), so the floor is already 20.

Suggestion:

"@types/node": "^20.0.0"

or match the minimum tested version. Rationale: @types/node should always reflect the minimum Node version you actually support to avoid invisible type gaps.

[Sourav-kashyap]

I’ll update this in a follow-up PR since it is a major version change

[rohit-sourcefuse]

This is a pure Prettier reflow — functionally identical to the old form. No issue with the change itself.

While I'm looking at this file, I'd like to flag a pre-existing race condition in VaultConnector.initContainer() (in vault-connector.ts) that this PR doesn't introduce but also doesn't fix. Every public method calls await this.initContainer() at the top, and initContainer is not guarded against concurrent calls:

// Current code in vault-connector.ts — concurrent calls can each hit !health.initialized simultaneously
async initContainer() {
  const health = await this._vaultClient.health(...);
  if (!health.initialized) {
    await this._initializeVault(); // called N times concurrently
  }
  ...
}

A lightweight fix using a promise-based guard:

private _initPromise: Promise<void> | null = null;

async initContainer() {
  if (!this._initPromise) {
    this._initPromise = this._doInit().catch(err => {
      this._initPromise = null; // allow retry on failure
      throw err;
    });
  }
  return this._initPromise;
}

private async _doInit() {
  const health = await this._vaultClient.health({ sealedcode: 200, uninitcode: 200 });
  if (!health.initialized) {
    await this._initializeVault();
  }
  if (health.sealed && health.initialized) {
    await this._vaultClient.unseal({ secret_shares: 1, key: this._config?.unsealKey ?? '' });
  }
}

Not a blocker for this PR since vault-connector.ts isn't changed here, but worth tracking as a follow-up issue.

[Sourav-kashyap]

ok sir, i’ll track this as a follow-up

[rohit-sourcefuse]

node-vault is not upgraded and is still on ^0.10.2 (released ~2021)

This PR upgrades virtually all other dependencies, but node-vault — the single most critical runtime dependency for a vault connector library — is left at ^0.10.2. The package has had releases since then.

I'd suggest checking if a newer version is available and whether it introduces breaking changes:

npm outdated node-vault

If the latest version is compatible, include it in this PR to keep the upgrade story complete. If there are breaking API changes, at minimum open a follow-up issue so it doesn't get lost. Leaving the core vault client behind while upgrading peripheral dev tooling is an asymmetric risk for a secrets management library.

[Sourav-kashyap]

resolved

[rohit-sourcefuse]

jsdom jumped from ^21 to ^29 — implicit Node.js minimum floor change

jsdom@29 and its new transitive dependencies (@asamuzakjp/css-color, @asamuzakjp/dom-selector) declare an engine requirement of ^20.19.0 || ^22.12.0 || >=24.0.0. This means Node 20.18.x and earlier will fail at runtime even though the CI matrix only pins 20 without a patch floor.

This isn't blocking today since CI runs on recent ubuntu-latest runners, but I'd suggest two small additions:

1. Add an engines field to package.json documenting the actual Node floor:

"engines": {
  "node": ">=20.19.0"
}

2. Pin the CI matrix to the minimum patch versions that satisfy the constraint:

matrix:
  node-version: ['20.19.0', '22.12.0', '24']

Rationale: consumers who install this package via npm and happen to be on Node 20.18 would get a broken transitive dep with no clear error message. Documenting the engine constraint makes the breakage explicit.

[Sourav-kashyap]

resolved

[rohit-sourcefuse]

Overview

This PR performs a broad dependency upgrade across package.json and package-lock.json, with one minor Prettier reformat in vault-connect.service.ts and a workflow change in trivy.yaml. All CI checks pass (Node 20/22/24 matrix, SonarCloud, Trivy).

What the PR does:

• Bumps all @loopback/* packages to latest patch releases (boot, core, rest, build, testlab)
• Upgrades @sourceloop/core from ^20.0.0 to ^20.0.6
• Upgrades tslib to ^2.8.1, husky from v7 to v9, jsdom from v21 to v29, nyc from v17 to v18
• Upgrades semantic-release toolchain (commit-analyzer v9→v13, release-notes-generator v10→v14, etc.)
• Changes aquasecurity/trivy-action from pinned @0.28.0 to @master in the Trivy workflow
• Reformats the class declaration in vault-connect.service.ts (Prettier reflow, no logic change)

---

Must-fix before merge

1. trivy.yaml: aquasecurity/trivy-action@master is unpinned — this is the most critical issue. Switching from @0.28.0 to @master means any commit pushed to the upstream action repo silently becomes part of your security-scanning pipeline. Please revert to a pinned version tag (e.g. @0.31.0) or a full commit SHA. Inline comment posted.

2. @types/node still at ^16.18.119 — the CI matrix tests Node 20, 22, and 24, and jsdom@29 transitively requires ^20.19.0 || ^22.12.0 || >=24.0.0. Node 16 type definitions are no longer accurate for the runtime being tested and shipped against. Bump to ^20.0.0 to match the actual minimum. Inline comment posted.

---

Nice-to-have follow-ups

• node-vault left at ^0.10.2: Every other dependency is bumped, but the core vault client itself is not. Worth a dedicated investigation — if there's a newer version available, it should either be included here or tracked as an immediate follow-up issue.

• actions/checkout@v3 and actions/setup-node@v3 in both trivy.yaml and main.yaml: v4 of both actions has been stable for over a year and includes security patches. Bump these while touching the workflow files to keep the upgrade story consistent.

• Node engine floor not documented: jsdom@29 pulls in dependencies that require Node ≥ 20.19.0. Adding an engines field to package.json and pinning the CI matrix to the minimum satisfying patch version would make this constraint explicit for downstream consumers.

• initContainer() race condition in vault-connector.ts (pre-existing, not introduced here): multiple concurrent vault operations each call await initContainer(), which can trigger parallel _initializeVault() calls. A promise-based init guard would close this. See the inline comment on vault-connect.service.ts for a suggested pattern — worth a follow-up issue.

• eslint held at ^8.57.0: ESLint 9 is now the current major. Not a blocker, but worth a follow-up given the rest of the toolchain was bumped.

[sonarqubecloud]

SonarQube reviewer guide

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud