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]

Pinning a GitHub Actions step to @master instead of a fixed commit SHA or immutable release tag introduces a supply chain security risk (OSSF Scorecard "Pinned-Dependencies" / CWE-829).

The previous version used @0.28.0, which is at least an immutable tag. Moving to @master means any future push to the aquasecurity/trivy-action master branch — including a compromised or broken commit — will be pulled into every workflow run without notice.

Suggestion: Pin to the latest release tag, or ideally to the full commit SHA of that release:

# Option 1 — immutable tag
- uses: aquasecurity/trivy-action@0.30.0

# Option 2 — SHA pin (most secure)
- uses: aquasecurity/trivy-action@18f2510ee396bbf400402947b394f2dd8c87dbb0 # v0.30.0

Rationale: Mutable refs like master are explicitly flagged by GitHub's security hardening guidelines and tools like Dependabot / StepSecurity Harden-Runner.

[Sourav-kashyap]

resolved

[rohit-sourcefuse]

tslib is already listed in the dependencies section ("tslib": "^2.6.2") and is now also added to devDependencies ("tslib": "^2.8.1") with a different version range. This creates two problems:

1. Version skew — library consumers will resolve ^2.6.2 from dependencies, while local development resolves ^2.8.1 from devDependencies. Any behavioral difference between 2.6.x and 2.8.x will be invisible until someone installs the package as a consumer.
2. Misleading signal — placing a runtime dependency in devDependencies can confuse tooling and contributors about the package's true runtime requirements.

Suggestion: Remove tslib from devDependencies and update the single entry in dependencies to the version you need:

// In dependencies only:
"tslib": "^2.8.1"

Then remove the duplicate entry from devDependencies entirely.

[Sourav-kashyap]

resolved

[rohit-sourcefuse]

I'd like to understand the intent here. @loopback/boot, @loopback/core, @loopback/repository, @loopback/rest, and @loopback/sequelize have been moved into devDependencies, yet they are referenced in the library's source and are listed as peerDependencies in the published package.json. @sourceloop/core is also added here.

This pattern is correct for peer dependency testing (installing them as devDeps satisfies the peer requirement locally and in CI), but it raises a few concerns:

1. Implicit coupling — if @sourceloop/core@^20.0.6 introduced breaking API changes this library relies on, those changes need to be reflected in source code, not just in the version range.
2. Missing peerDependencies update — if these packages are now at major/minor version bumps, the peerDependencies block in package.json should be updated accordingly so consumers get correct version resolution warnings. Has the peerDependencies block been reviewed?
3. @loopback/sequelize being a devDep is appropriate since it's an optional integration — just confirming that @loopback/sequelize is NOT listed in dependencies or peerDependencies (so consumers who don't use Sequelize aren't forced to install it).

Could you confirm the peerDependencies ranges have been reviewed for each of these packages?

[Sourav-kashyap]

resolved

[rohit-sourcefuse]

The typescript version is still pinned to ~5.2.2, which was released in September 2023. TypeScript is now at 5.7.x (as of early 2025). This is a dependency-upgrade PR — it seems intentional to stay on 5.2.x, but it's worth being explicit about it.

If the decision is to stay on ~5.2.2, a comment in the PR description or a CHANGELOG entry explaining the constraint (e.g., LoopBack build compatibility) would be helpful. If there is no blocker, I'd suggest taking this opportunity to update to at least ~5.4.x or ~5.6.x:

"typescript": "~5.6.3"

Older TypeScript versions miss language improvements and bug fixes that could affect type checking accuracy in the mixin and decorator code this library relies on.

[Sourav-kashyap]

resolved

[rohit-sourcefuse]

Overall Review

What this PR does:

• Bumps all devDependencies to their latest patch/minor versions (commitlint, ESLint, semantic-release, simple-git, cz-customizable, etc.)
• Adds @loopback/boot, @loopback/core, @loopback/repository, @loopback/rest, @loopback/sequelize, and @sourceloop/core as explicit devDependencies (previously resolved transitively)
• Adds @sourceloop/core@^20.0.6 as a new devDependency
• Adds jsdom@^24.1.3 as a new devDependency — purpose unclear
• Adds tslib@^2.8.1 to devDependencies while tslib@^2.6.2 remains in dependencies — creates a version-skew issue
• Reformats the @semantic-release/npm config block in package.json (cosmetic only)
• Reformats the SequelizeCrudRepository generic type parameters in audit.mixin.ts (whitespace/formatting only — no logic change)
• Changes the Trivy GitHub Actions step from a pinned tag (@0.28.0) to the mutable @master ref — this is a regression from a security standpoint
• All CI checks (node matrix tests on 20/22/24, npm audit, SonarCloud, Trivy) are currently passing

---

Must-fix before merge

1. trivy.yaml — @master pinning is a security regression. The previous @0.28.0 was an immutable tag; @master is a mutable ref that can be silently updated with breaking or malicious code at any time. Pin to a specific release tag or commit SHA. See inline comment.

2. tslib duplicate in dependencies and devDependencies with different version ranges. ^2.6.2 (runtime) vs ^2.8.1 (dev) will resolve differently for consumers vs local dev. The runtime entry in dependencies should be updated to ^2.8.1 and the devDependencies entry removed. See inline comment.

3. jsdom — intent unclear. An audit-log library has no obvious DOM requirement. If this is a transitive dependency accidentally promoted to a direct one, it should be removed. If genuinely needed, it needs a clear explanation. See inline comment.

---

Nice-to-have follow-up

• Confirm peerDependencies ranges have been reviewed alongside the newly-explicit devDep versions for @loopback/* and @sourceloop/core — consumers relying on peer resolution should get accurate warnings.
• Consider updating typescript from ~5.2.2 to a more recent ~5.6.x or ~5.7.x while the dependency train is already moving. No logic changes are needed; the reformatted mixin code compiles fine on newer TS.
• The PR description mentions "Fixed breaking changes introduced by major version upgrades" — it would help reviewers to know which packages had breaking changes and what was done to address them, especially given @actions/core jumping from 1.x to 3.0.0.
• Consider setting up Dependabot or Renovate for automated, incremental dependency updates to avoid these large batch upgrades in the future.

[rohit-sourcefuse]

jsdom is a full DOM implementation package that is generally used for unit-testing browser-environment code (React components, DOM manipulation, etc.). This package does not appear to have any obvious use in an audit-log library.

I'd flag this as an unexpected addition — could you explain why jsdom@^24.1.3 is needed? A few things to check:

• Is it pulled in transitively by another devDep upgrade (e.g., a test runner config)? If so, it shouldn't need to be in package.json directly.
• If it is genuinely required for tests, a comment or a test file referencing it would clarify the intent.
• jsdom@24.x requires Node ≥ 18 — that aligns with the project's engine constraints, so no issue there, just worth confirming the test setup explicitly relies on it.

If this is a transitive pull-in that got accidentally promoted to a direct dependency, it should be removed.

[Sourav-kashyap]

jsdom is directly used in src/release_notes/post-processing.js to scrape GitHub issue titles during the
release process. It's NOT transitive

[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