chore(deps-dev): bump @types/node from 25.0.9 to 25.2.0 in /apps/admin

[dependabot]

Bumps @types/node from 25.0.9 to 25.2.0.

Commits

• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[fingertips18]

@coderabbitai Are there any breaking changes in this dependency update? Is it safe to merge?

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

• 🔍 Trigger a full review

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🌐 Web query:

`@types/node` 25.1.0 25.2.0 changelog breaking changes

💡 Result:

There aren’t any @types/node releases 25.1.0 or 25.2.0, so there’s no @types/node 25.1.0 → 25.2.0 changelog or breaking-change list to consult. The npm package’s published 25.x line uses versions like 25.0.x (e.g., 25.0.10 on Jan 21, 2026) rather than tracking Node’s 25.1/25.2 minors directly. [1]

If what you actually meant is Node.js 25.1.0 → 25.2.0 (runtime/API changes that @types/node later reflects), Node’s release notes list only semver-minor notable changes (primarily additive), e.g. util.deprecate options, “type stripping” marked stable, etc. [2] [3]

Also, DefinitelyTyped does not provide a dedicated, per-version breaking-changes changelog for @types/node; the usual approach is to inspect the PR/commit diffs (or just try the upgrade and see what TypeScript errors appear). [4]

Sources: [1] [2] [3] [4]

---

🌐 Web query:

`@types/node` version 25.2.0 npm release

💡 Result:

There doesn’t appear to be an npm release @types/node@25.2.0.

@types/node versions track Node’s major/minor line, but the published package versions for the Node 25 line are 25.0.x (not 25.2.x). For example, npm trackers/CDNs show the Node 25 typings line at 25.0.10 (published Jan 21, 2026) and other 25.0.x patches. [1] [2]

If you’re looking for the runtime release Node.js v25.2.0, that was released on Nov 11, 2025. [3]

What to install for Node 25.2.0: use the latest @types/node@25 (i.e., a 25.0.x version), not 25.2.0. [1] [2] [3]

Sources:
[1] (releasealert.dev)
[2] (jsdelivr.com)
[3] (nodejs.org)

Citations:

• 1: https://releasealert.dev/npmjs/%40types/node?utm_source=openai
• 2: https://www.jsdelivr.com/package/npm/%40types/node?utm_source=openai
• 3: https://nodejs.org/en/blog/release/v25.2.0?utm_source=openai

---

🏁 Script executed:

#!/bin/bash
# Check the package.json file in apps/admin to see the actual version
cat apps/admin/package.json | jq '.devDependencies["@types/node"]'

# Also check if there's a package-lock.json
if [ -f apps/admin/package-lock.json ]; then
  cat apps/admin/package-lock.json | jq '.packages["node_modules/@types/node"].version' 2>/dev/null || echo "Version not found in specific path"
fi

# Check for any git diff to see what's actually changing
git diff HEAD~1 HEAD -- apps/admin/package.json 2>/dev/null || echo "Cannot show diff"

Length of output: 422

---

🌐 Web query:

"@types/node" "25.2.0" npm published

💡 Result:

Evidence is mixed:

• Snyk’s npm version metadata indicates @types/node 25.2.0 is published and lists it as the latest version, “published 9 hours ago” (relative to their page crawl). [1]
• However, other public trackers still show 25.0.10 (Jan 21, 2026) as the latest release. [2][3][4]

So: 25.2.0 appears to have been published on npm, but some indexes haven’t caught up yet (or one source may be stale/incorrect). [1][2][3][4]

Sources: [1] [turn1search3], [2] [turn6search0], [3] [turn8search9], [4] [turn8search2]

---

🌐 Web query:

`@types/node` 25.0.9 vs 25.2.0 changes differences

Error during web search

---

🌐 Web query:

`@types/node` type definitions breaking changes minor versions

💡 Result:

• @types/node does not follow “SemVer for types” in the way many people expect. In DefinitelyTyped, the major.minor of @types/node is meant to track the Node.js major.minor line, while the patch number is incremented whenever the typings change (for that same Node major.minor). This means breaking type changes can land in patch releases, because DT can’t “save” them for a major bump unless Node itself bumps major.minor. [1]

• So “minor updates” of @types/node are not “safe” in the SemVer sense. A bump from e.g. 18.12.x → 18.13.x is primarily “you’re now on the Node 18.13 typings line”, not “backwards-compatible changes only”. [1]

• A common real-world cause of breakage is TypeScript-version gating / syntax changes inside @types/node. Example: @types/node@18.13.0 introduced a typesVersions mapping (including a ts4.8/* subtree), and users on older TypeScript versions reported build breaks after npm/yarn pulled the newer minor. [2]

• This interacts with the broader reality that TypeScript itself can introduce breaking changes in “minor” releases, so type packages that adopt newer TS features can break consumers who haven’t upgraded TS. [3]

Practical mitigations:

• Pin @types/node to an exact version (or at least to a specific major.minor.patch) instead of ^ if you need repeatable builds.
• Align your TypeScript version with the @types/node line you’re upgrading to, and expect that upgrading either can require code changes.

Sources: [1] DefinitelyTyped README on versioning and breaking changes policy for @types/* packages, including @types/node [2] DefinitelyTyped discussion: @types/node@18.13.0 breaking due to typesVersions/TS-version interactions [3] “TypeScript’s Versioning Policy” (SemVer for TS types): minor releases may be breaking.

---

🏁 Script executed:

#!/bin/bash
# Check TypeScript version in the admin app
cat apps/admin/package.json | jq '.devDependencies.typescript // .dependencies.typescript // "not found"'

# Check if there are any TypeScript config files
ls -la apps/admin/tsconfig*.json 2>/dev/null || echo "No tsconfig files found"

# Look for any TypeScript compiler errors or build scripts
cat apps/admin/package.json | jq '.scripts'

Length of output: 422

---

🏁 Script executed:

#!/bin/bash
# Check what Node.js APIs are being used in the admin app
echo "=== Checking Node.js built-in module imports ==="
rg "from ['\"]node:" apps/admin/src --type ts --type tsx 2>/dev/null || rg "require\(['\"]node:" apps/admin/src --type ts --type tsx 2>/dev/null || echo "No explicit node: imports found"

# Also check for common Node.js globals/APIs
echo -e "\n=== Checking for process usage ==="
rg "\bprocess\." apps/admin/src --type ts --type tsx -C 1 2>/dev/null | head -20 || echo "No process usage found"

# Check for Buffer usage
echo -e "\n=== Checking for Buffer usage ==="
rg "\bBuffer\." apps/admin/src --type ts --type tsx -C 1 2>/dev/null | head -10 || echo "No Buffer usage found"

# Check vite config which often uses Node APIs
echo -e "\n=== Checking vite.config.ts ==="
cat apps/admin/vite.config.ts 2>/dev/null || echo "No vite.config.ts found"

Length of output: 1930

---

@fingertips18, Based on my analysis, this update appears to be safe to merge, but with a few important considerations:

What's Changing

@types/node version numbering tracks Node.js major.minor versions, so this bump from 25.0.9 to 25.2.0 brings type definitions aligned with Node.js 25.2.x APIs.

Risk Assessment: LOW ✅

Why it's likely safe:

1. Type definitions only - No runtime code changes, only TypeScript type information
2. Modern TypeScript version - Your app uses TypeScript ~5.9.3, which is fully compatible
3. Minimal Node.js API usage - I checked your codebase and found only standard APIs in vite.config.ts:
   • process.cwd()
   • path.resolve()
   • __dirname
4. Same major version - Staying within Node.js 25.x

Important caveat:
@types/node can introduce breaking type changes in minor/patch releases because DefinitelyTyped prioritizes tracking Node.js versions over strict semver. However, breaking changes are uncommon for standard APIs you're using.

Recommendation

Before merging:
Run the TypeScript build to confirm no type errors:

cd apps/admin && npm run build

If the build passes without new TypeScript errors, you're good to merge! The CI checks should also verify this.

Note: Your package.json uses ^25.2.0, which means future patch updates (25.2.1, 25.2.2, etc.) will be automatically installed. This is standard practice for type definitions.