Expand hrtime utility to support Web Workers.

[AlasDiablo]

Hi,

I need to use the dicom codecs inside a worker for applying redaction into the pixel data; I got a crash from the processTimer.js util.
I tried this locally and it's now working.

I have also a question about the default return value; it is not preferable to return [0,0] instead of 0 to avoid crashing in other environments. The only downside is having a false duration given by this util.

Have a nice day.

Summary by CodeRabbit

• Bug Fixes

  • Improved timer functionality to properly work across different execution environments, including web workers.

• Documentation

  • Expanded documentation for timer utility functions.

[coderabbitai]

📝 Walkthrough

Walkthrough

processTimer.js is updated to import isWebWorker from browser-or-node, add JSDoc to the hrtime helper, and introduce a new isWebWorker branch in hrtime that computes elapsed time using performance.now() instead of Node's process.hrtime.

Changes

Web Worker hrtime Support

Layer / File(s)	Summary
isWebWorker detection and hrtime extension packages/dicom-codec/src/utils/processTimer.js	Adds isWebWorker to the browser-or-node destructured import, expands JSDoc on the hrtime helper, and inserts a new isWebWorker conditional branch that uses performance.now() to compute elapsed time; adds a comment clarifying the [0, 0] fallback for unrecognized environments.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Poem

🐇 Hippity-hop through threads and frames,
A worker arrives and stakes its claims.
performance.now() ticks the clock right,
No Node, no browser — still timing's bright!
The timer hops on, ears perked with cheer. ✨

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately reflects the main change in the pull request, which is expanding the hrtime utility to support Web Workers as implemented in processTimer.js.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@packages/dicom-codec/src/utils/processTimer.js`:
- Around line 16-20: The hrtime function has an inconsistent return type that
causes crashes when the return value is indexed. The JSDoc currently indicates
the return type can be either a tuple [number, number] or a plain number, but
the code at line 54 always indexes into the result with [0] and [1]. Update the
JSDoc in the comment block to only specify [number, number] as the return type,
and then locate the return statement around line 50 that currently returns the
numeric value 0 and change it to return a tuple format [0, 0] to maintain
consistency with the expected contract that all code paths return a tuple.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 2e5e1c9a-983b-4a0f-a485-f2b145f2c215

📥 Commits

Reviewing files that changed from the base of the PR and between 04c3e87 and abf9e28.

📒 Files selected for processing (1)

• packages/dicom-codec/src/utils/processTimer.js

[coderabbitai]

🩺 Stability & Availability | 🟠 Major | ⚡ Quick win

Make hrtime return shape consistent across all branches.

Line 50 returns 0, but downstream code assumes a tuple and indexes time[0]/time[1] (Line 54). In unsupported runtimes this can still crash. Keep the contract tuple-only and align JSDoc accordingly.

Proposed fix

   /**
-   *
-   * `@return` {[number, number]|number}
-   * `@param` previousTime{[number, number]}
+   * `@param` {[number, number]} [previousTime]
+   * `@returns` {[number, number]}
    */
   function hrtime(previousTime) {
@@
-    // Return [0, 0] to avoid crash in other environments?
-    return 0;
+    // Fallback: preserve tuple contract to avoid downstream crashes.
+    return [0, 0];
   }

Also applies to: 49-50

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/dicom-codec/src/utils/processTimer.js` around lines 16 - 20, The
hrtime function has an inconsistent return type that causes crashes when the
return value is indexed. The JSDoc currently indicates the return type can be
either a tuple [number, number] or a plain number, but the code at line 54
always indexes into the result with [0] and [1]. Update the JSDoc in the comment
block to only specify [number, number] as the return type, and then locate the
return statement around line 50 that currently returns the numeric value 0 and
change it to return a tuple format [0, 0] to maintain consistency with the
expected contract that all code paths return a tuple.