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 dev dependency bumps with no application source changes; main risk is CI/local test or build behavior if Vitest/Vite regress.

Overview
This PR refreshes package-lock.json only (no package.json changes), consistent with an npm audit fix for AP-10424.

The lockfile pulls newer dev-tooling versions, mainly through Vitest’s dependency tree: Vitest and its @vitest/* packages move 4.1.8 → 4.1.11, and Vite moves 8.0.16 → 8.3.0 with rolldown ~1.2.6 (bindings 1.0.3 → 1.2.9), lightningcss 1.33.0, and updated postcss / nanoid. Several other transitive packages bump (e.g. js-yaml, @humanfs/*, @oxc-project/types).

The tree also drops some optional WASM-related packages (@emnapi/*, @napi-rs/wasm-runtime, @rolldown/binding-wasm32-wasi) and hoists picomatch instead of nesting it under Vite/Vitest/tinyglobby.

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