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]

I'd strongly recommend against using aquasecurity/trivy-action@master here. Pinning to a mutable branch reference means the action can change under you at any point without any notice — a new commit to master could introduce breaking changes, alter scan behaviour, or in a supply-chain attack scenario, inject malicious code into your CI pipeline.

The original @0.28.0 tag was the right approach. Please pin to a specific release tag or, ideally, to the immutable commit SHA of a known-good release:

# Option A — pin to a release tag (good)
- uses: aquasecurity/trivy-action@v0.30.0

# Option B — pin to commit SHA (best, supply-chain safe)
- uses: aquasecurity/trivy-action@18f2510ee396bbf400402947b394f2dd8c87dbb0  # v0.30.0

Using @master in a security-scanning workflow is particularly ironic — the tool meant to catch vulnerabilities is itself running from an unpinned source.

[Sourav-kashyap]

resolved

[rohit-sourcefuse]

The new lodash override specifies "^4.18.0" but the latest stable release of lodash v4 is 4.17.21 — there is no 4.18.x. This semver range will never resolve to an actual published version and npm will silently fall back to the highest available version within the range (which is 4.17.21), potentially causing confusing resolution behaviour or a silent no-op.

Please correct the version to match what is actually published:

// package.json overrides
"lodash": "^4.17.21"

Also worth noting: if the intent here is to remediate a security advisory on lodash, 4.17.21 is the latest and already patches the known prototype-pollution CVEs (CVE-2019-10744, CVE-2020-8203). No newer patch exists.

[rohit-sourcefuse]

Overall Review

What this PR does:

• Bumps all dependencies and devDependencies in package.json and regenerates package-lock.json
• Upgrades core LoopBack packages (@loopback/boot, @loopback/core, @loopback/rest, @loopback/context) to latest patch releases
• Upgrades several major devDependency versions: commitlint v17→v20, husky v7→v9, jsdom v21→v29, nodemailer v6→v8, nyc v17→v18, pubnub v8→v10, typescript ~5.2.2→~5.7.3, @parse/node-apn v5→v8, @semantic-release/* toolchain
• Adds three new overrides entries: lodash, undici, picomatch (vulnerability remediation)
• Updates the Trivy CI action reference from @0.28.0 to @master
• Bumps @types/node from ^16 all the way to ^25

---

Must-fix before merge

1. Trivy action pinned to @master — This is a security regression. A mutable branch reference in a supply-chain-sensitive security scanner is unacceptable. Pin to a specific release tag or commit SHA (e.g., aquasecurity/trivy-action@v0.30.0). See inline comment.

2. lodash override version ^4.18.0 does not exist — The latest lodash v4 is 4.17.21. There is no 4.18.x published. This override is silently ineffective. Change to ^4.17.21. See inline comment.

3. aws-sdk v2 is EOL — AWS ended maintenance for SDK v2 on September 8, 2025. It will receive no further security patches. This PR bumps it to ^2.1693.0 but should migrate to the modular @aws-sdk/client-* v3 packages (which are already present as transitive deps). If migration is out of scope, open and link a tracked issue. See inline comment.

4. twilio not upgraded — Still at ^3.82.0 while Twilio Node SDK v5.x is current. Twilio v3 is maintenance-only. Either upgrade or document the deferral with a follow-up issue. See inline comment.

5. Husky v7→v9 migration completeness — The .husky/ hook files likely need to be updated to v9 format (no shebang, no husky.sh source line). If those files were not updated in this PR, fresh contributor installs will encounter broken hooks. Please confirm and include the .husky/ changes. See inline comment.

---

Nice-to-have follow-ups

• @types/node@25.x vs LTS runtime — Using ^25.5.0 types when the minimum engine is Node 20 LTS can mask runtime availability issues. Consider aligning types to ^20.19.0 or ^22.15.0. See inline comment.

• firebase-admin not upgraded — Still at ^12.1.1; current stable is v13.x. Inconsistent with the stated goal of upgrading all deps to latest.

• @parse/node-apn v5→v8 (3 majors) — Confirm test coverage exercises the APN send path with the new major version. Three major versions is a significant jump for a notification-critical library.

• @semantic-release/commit-analyzer v9→v13 — This is a significant jump in the release toolchain. Worth manually running a dry-run release to confirm the changelog and version-bump behaviour is as expected before merging.

• nodemailer v6→v8 — Major version bump in the email transport layer. Ensure the @types/nodemailer upgrade to ^7 covers the v8 API surface and that any nodemailer-specific test coverage is in place.

• Consider running npm audit output as a CI artifact or adding it as a step to the workflow so future PRs make the security posture of the lock file explicit.

[rohit-sourcefuse]

The @parse/node-apn package jumped from ^5.1.3 to ^8.0.0 — three major versions at once. This is the APN (Apple Push Notifications) provider, and major version bumps in this library typically mean changes to the provider API, token/certificate handling, or HTTP/2 connection management.

Since this is a devDependency used in tests, the risk is somewhat contained, but the test suite should explicitly cover the APN notification path to confirm the integration still works correctly with the new major version. Based on the PR checklist, npm test passes is confirmed, but I'd want to be sure there are tests that actually exercise the APN code path and not just that the suite exits cleanly.

Could you confirm that the APN-related tests (if any) are passing and cover the send/token/certificate flows? If there are no APN-specific tests, that's a gap worth tracking separately.

[rohit-sourcefuse]

The @types/node version jumped from ^16.18.119 to ^25.5.0 — that's a 9-major-version leap. While the engines field requires node >= 20, the @types/node@25.x declarations correspond to Node 25 APIs (which is currently an odd-numbered, non-LTS release). This can introduce type errors if your source code unintentionally starts referencing APIs that do not exist in Node 20 or 22 LTS at runtime.

I'd suggest aligning the types with the minimum supported runtime version:

// For Node 20 LTS (recommended — matches lowest engine requirement)
"@types/node": "^20.19.0"

// Or for Node 22 LTS
"@types/node": "^22.15.0"

Using @types/node@25.x when your runtime target is Node 20/22 LTS could hide runtime errors behind passing TypeScript compilation.

[rohit-sourcefuse]

The aws-sdk dependency is still on v2 (^2.1693.0). AWS officially ended maintenance for AWS SDK for JavaScript v2 on September 8, 2025 — it will receive no further security patches or bug fixes.

The recommended path is to migrate to the modular AWS SDK v3 (@aws-sdk/client-ses, @aws-sdk/client-sns, etc.), which is already present as a transitive dependency in this very lock file (e.g., @aws-sdk/client-ses). Continuing to ship v2 in production means accepting known-unpatched CVEs after the EOL date.

Suggested migration:

// Remove from devDependencies:
// "aws-sdk": "^2.1693.0"

// Add the specific clients you actually use, e.g.:
"@aws-sdk/client-ses": "^3.x.x",
"@aws-sdk/client-sns": "^3.x.x"

If this is a deliberate deferral due to migration scope, please open a tracked issue and document it here.

[rohit-sourcefuse]

I noticed firebase-admin is still at ^12.1.1 and was not bumped in this upgrade sweep. The current stable release is v13.x. Firebase Admin v13 contains a number of dependency updates and bug fixes. While this is a minor concern compared to the aws-sdk/twilio gaps, it's worth keeping consistent with the stated goal of upgrading all dependencies to latest.

Please either upgrade it here or track the deferral explicitly:

"firebase-admin": "^13.0.0"

[rohit-sourcefuse]

The husky upgrade from 7.0.4 to 9.1.7 spans two major versions and includes breaking changes. Husky v8 removed the .husky/_/husky.sh shim, and husky v9 moved from a manual prepare script setup to a single husky binary call.

Specifically:

• v8+ no longer uses the prepare: "husky install" pattern — the setup command is now just husky in the prepare script
• Hook files in .husky/ no longer need the #!/usr/bin/env sh shebang header or the . "$(dirname -- "$0")/_/husky.sh" source line — husky v9 ignores those and they can cause failures on CI

If the .husky/ directory is tracked in this repo and still contains v7-style hook files, they need to be updated. This PR should include those changes or the prepare step will silently fail on fresh installs.

Please verify the .husky/ hook files are compatible with v9 format, e.g.:

# .husky/commit-msg (v9 format — no shebang, no source line needed)
npx --no -- commitlint --edit $1

[rohit-sourcefuse]

I noticed twilio is still pinned at ^3.82.0 and was not upgraded as part of this sweep. The current stable release of the Twilio Node.js SDK is v5.x (released ~Q1 2024), which is a major version bump from v3. Twilio v3 is in maintenance-only mode and will eventually reach end-of-life.

v5 brings significant breaking changes (new import paths, updated REST client structure, dropped Node <18 support), so I understand if this was intentionally deferred — but if so, please open a follow-up issue to track it. If it was accidentally missed, it should be addressed here for consistency with the rest of the upgrade.

// package.json
"twilio": "^5.3.7"

At a minimum, please add a comment or a TODO issue reference explaining why this was left at v3.

[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