Skip to content

Upgrade systeminformation to 5.x, clearing the last advisories - #7

Merged
sachinsachdeva merged 1 commit into
mainfrom
chore/upgrade-systeminformation
Aug 29, 2026
Merged

Upgrade systeminformation to 5.x, clearing the last advisories#7
sachinsachdeva merged 1 commit into
mainfrom
chore/upgrade-systeminformation

Conversation

@sachinsachdeva

Copy link
Copy Markdown
Owner

systeminformation is the extension's only production dependency and the only one that ships. Every version up to 5.31.6 carries command-injection advisories — eleven of them. Clearing those means 4.x → 5.x, which renames most of the surface this extension reads.

npm audit now reports 0 vulnerabilities, down from 8 (1 critical, 5 high, 1 moderate, 1 low).

Stacks on #6. This branch contains that commit, so merging this alone also lands the dev-dependency patches. Merge #6 first if you'd rather keep them separate.

Renames that would have broken readings, not merely changed them

What v4 v5 Consequence if missed
CPU frequency si.cpuCurrentspeed() si.cpuCurrentSpeed() Throws. ResMon.update() gathers resources with Promise.all and has no error handling, so the entire status bar freezes
CPU usage currentload_idle etc. currentLoadIdle etc. undefined → usage renders as NaN%
CPU temp main === -1 when absent main === null Check was !== -1, so a Mac with no sensor shows "null C"
Battery hasbattery, ischarging, … hasBattery, isCharging, … Battery section never appears

fsSize() changed meaning, and for the better

use is now used ÷ (used + available) — what df reports — where it was used ÷ size. On APFS those differ sharply, because every volume in a container reports the container's size. v5 also exposes available directly, so free space is no longer computed as size - used:

                         v4 (size - used)   v5 (available)   df
free space on this Mac        37 GB             9.80 GB      9883M
percent used                  16.22%            95.11%       96%

The old figures were wrong, not merely different. All four disk.format modes were checked against df.

Verification

Run on an Apple M4 against system tools:

Reading Result
CPU usage + user/system split 21.59% (13.94% user, 7.65% system)
Per-core load bars ▄▃▂▂▂▁▂▂▂▂ peak 45% on core 0
CPU frequency 2.40 GHz
CPU temperature correctly absent (no sensor) rather than null C
Memory / swap 14.16 GB of 16.00 GB (88.48%), swap 6.21 GB of 7.00 GB
Disk, all four formats match df (4.89% remaining, 9.80 GB free)
Battery hidden — see caveat below

48 tests pass, npm run lint clean, and the extension was smoke-tested through a mocked vscode module with every section rendering and the host exiting cleanly.

Caveat worth knowing: this machine has no battery, so those code paths could not be exercised at runtime. Instead every property the code reads off battery() was cross-checked against the keys v5 actually returns — all seven present. That is weaker than a live check, and a reviewer on a laptop could confirm it in a moment.

Also corrected: the comment claiming si.cpu() throws on Apple Silicon. It no longer does.

🤖 Generated with Claude Code

systeminformation is the extension's only production dependency and the
only one that ships, and every version up to 5.31.6 carries command
injection advisories -- eleven of them. Clearing those means 4.x to 5.x,
which renames most of the surface this extension reads. npm audit now
reports no vulnerabilities at all, down from eight.

Four of the renames would have broken readings rather than merely changing
them:

- si.cpuCurrentspeed() no longer exists under that spelling; it is
  cpuCurrentSpeed(). Calling the old name throws, and ResMon.update()
  gathers every resource with Promise.all and has no error handling, so
  this would have frozen the whole status bar rather than just the CPU
  frequency.
- currentLoad reports currentLoadIdle, currentLoadUser and
  currentLoadSystem where it used currentload_idle and friends. Reading
  the old names yields undefined, so the usage percentage would have
  rendered as NaN.
- cpuTemperature reports null where there is no readable sensor, having
  previously reported -1. The check was for -1 exactly, so a Mac with no
  exposed sensor -- which includes Apple Silicon -- would have shown
  "null C". It now tests for a usable number rather than for either way of
  saying there isn't one.
- battery reports hasBattery, isCharging, cycleCount, designedCapacity,
  maxCapacity, timeRemaining and acConnected in camelCase.

fsSize() changed meaning rather than spelling, and for the better. Its
"use" is now used over used-plus-available, which is what df reports, where
it was used over size; on APFS those differ sharply because every volume in
a container reports the container's size. v5 also reports "available"
directly, so free space is no longer computed as size minus used, which on
this machine claimed 37GB free where df said 9.9GB. All four disk formats
were checked against df.

Verified on an Apple M4 against system tools: CPU usage with its user and
system split, per-core load bars, frequency, memory, swap and all four disk
formats. The CPU temperature row is now correctly absent rather than
reading "null C". This machine has no battery, so those field names were
checked against the keys v5 actually returns rather than at runtime.

The note about si.cpu() throwing on Apple Silicon is no longer true and has
been corrected.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@sachinsachdeva
sachinsachdeva force-pushed the chore/upgrade-systeminformation branch from c7da00e to 50d5262 Compare August 29, 2026 12:35
@sachinsachdeva
sachinsachdeva merged commit d047f4c into main Aug 29, 2026
2 checks passed
@sachinsachdeva
sachinsachdeva deleted the chore/upgrade-systeminformation branch August 29, 2026 12:36
@sachinsachdeva sachinsachdeva mentioned this pull request Aug 29, 2026
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant