AP-10424 # npm audit fix

[kizaonline]

Requester Checklist

Please only check the items that you have actioned. Do not check items that are not applicable to your PR.

Implementation

• Have you tested your implementation locally?
• If applicable, has an appropriate changelog entry been added? Do not include if you are fixing/changing something that is only in the current release.
• There are no warnings that have been suppressed unnecessarily
• Have automated tests been added, or have related ones been updated to cover the change?
• Have all OneBlink dependency updates been completed (eg apps / apps-react / types etc).
• Have you ensured this change does not add unwanted dependencies?
• If this PR contains a refactor, have relevant Jira testing tasks added?
• Changes that will knowingly make the feature/bug incomplete have been commented with TODO and a description of what needs to be done to finish the feature/bug
• Any changes made to public APIs have been reflected in the documentation
• Have you isolated business logic where possible to allow for unit testing?

Logging and Debugging

• Are the error messages, if any, informative?
• Are there enough log events and are they written in a way that allows for easy debugging?
• "Debugging" code removed
• Front-end: No erroneous Console.WriteLines

Readability

• All class, variable, property and method modifiers are provided with the smallest scope possible
• New files, variables and functions are descriptive/comprehensible and named consistently.
• There is no dead code (unreachable code)
• There is no usage of magic numbers
• There is no commented out code.
• In hard-to-understand areas, comments exist and describe rationale or reasons for decisions in code

Security

• All personal data inputs are checked (for the correct type, length/size, format, and range).
• No sensitive information is logged or visible in a stacktrace
• Are authorization and authentication handled correctly?
• Is (user) input validated, sanitized, and escaped to prevent security attacks such as cross-site scripting or SQL injection?
• Is data retrieved from external APIs or libraries checked for security issues?
• Do API endpoints return appropriate status codes

Reviewer Guide

• It is important that you understand the purpose of the PR.
• You are encouraged to engage with the requestor if you do not understand any of the proposed code changes/additions/deletions.
• Do you, the reviewer, understand what the code does? Do you think a specific expert, like a security expert or a usability expert, should look over the code before it can be accepted?
• Is a framework, API, library, or service used that should not be used? Are there alternatives you could recommend?
• Are there existing hooks/components/functions in the same code base that could be utilised?
• When reviewing tests, attempt to identify missing edge cases that may be relevant to the proposed implementation
• Ensure you check for:
  • Security
  • Scalability
  • Performance
  • Maintainability

---

Note

Low Risk
Lockfile-only dependency bumps; nodemailer is a runtime dep but changes are patch/minor—verify tests and any email paths after install.

Overview
Refreshes package-lock.json only (AP-10424 / npm audit fix)—no application source changes.

Direct runtime deps resolve to newer versions: joi (18.2.3 → 18.2.9) and nodemailer (9.0.3 → 9.1.1).

Dev/test toolchain moves with the lockfile refresh: vitest and its @vitest/* packages (4.1.8 → 4.1.11), plus transitive vite (8.0.16 → 8.3.0), rolldown (1.0.3 → 1.2.9), lightningcss, and related native bindings. Optional WASM/emnapi packages tied to the older rolldown stack are dropped; @rolldown/binding-android-arm-eabi is added and several Linux bindings now declare libc metadata.

Smaller transitive bumps include postcss, nanoid, js-yaml, and @humanfs/* (with new @humanfs/types).

^{Reviewed by Cursor Bugbot for commit ba1ac9e. Bugbot is set up for automated code reviews on this repo. Configure here.}