Skip to content

fix: round chart numbers in applyDataCorrection for consistent rounding#2556

Merged
graphieros merged 6 commits intonpmx-dev:mainfrom
ulrichstark:fix--round-downloads-to-avoid-fractions-showing-up-when-hovering-WeeklyDownloadStats
Apr 18, 2026
Merged

fix: round chart numbers in applyDataCorrection for consistent rounding#2556
graphieros merged 6 commits intonpmx-dev:mainfrom
ulrichstark:fix--round-downloads-to-avoid-fractions-showing-up-when-hovering-WeeklyDownloadStats

Conversation

@ulrichstark
Copy link
Copy Markdown
Contributor

@ulrichstark ulrichstark commented Apr 17, 2026

🔗 Linked issue

There's not.
This is a pretty straightforward and tiny fix.

🧭 Context

The weekly download charts shows numbers with fraction when hovering over it and smoothing is enabled:

image

Here you can see the exact number of the screenshot coming in to the code location I'm changing with this PR:

image

📚 Description

Download numbers are now rounded up before showing them to the user.
I can also do the change in applyDataCorrection instead if that's preferred.

@vercel
Copy link
Copy Markdown

vercel bot commented Apr 17, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
npmx.dev Ready Ready Preview, Comment Apr 18, 2026 7:31am
2 Skipped Deployments
Project Deployment Actions Updated (UTC)
docs.npmx.dev Ignored Ignored Preview Apr 18, 2026 7:31am
npmx-lunaria Ignored Ignored Apr 18, 2026 7:31am

Request Review

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai bot commented Apr 17, 2026

📝 Walkthrough

Walkthrough

Chart data values are now ceiling-rounded after smoothing; several components stopped forcing zero fractional digits in number formatting, and a tooltip formatter was changed to use the raw numeric value (no Math.round).

Changes

Cohort / File(s) Summary
Chart Data Correction Post‑Processing
app/utils/chart-data-correction.ts
applyDataCorrection now maps smoothed points to copies and replaces each value with Math.ceil(d.value), changing returned values to ceiling-rounded integers.
Number formatting defaults removed
app/components/Chart/SplitSparkline.vue, app/components/Package/WeeklyDownloadStats.vue
Removed explicit { maximumFractionDigits: 0 } when calling useNumberFormatter(), so formatting follows the formatter’s default fraction-digit behaviour.
Tooltip value precision change
app/components/Package/TrendsChart.vue
Tooltip value computation uses Number(...) instead of Math.round(Number(...)), so tooltips display the unrounded numeric value (with Number.isFinite fallback).
🚥 Pre-merge checks | ✅ 2
✅ Passed checks (2 passed)
Check name Status Explanation
Description check ✅ Passed The description is directly related to the changeset, providing context about the fractional numbers issue, demonstrating the problem with screenshots, and explaining the solution approach.
Title check ✅ Passed The title states 'round chart numbers in applyDataCorrection', but the primary change involves ceiling-rounding with Math.ceil plus formatter adjustments across multiple components. The title partially describes the main technical change but omits the broader context of formatter updates in other components.

✏️ 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

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

@github-actions
Copy link
Copy Markdown

Hello! Thank you for opening your first PR to npmx, @ulrichstark! 🚀

Here’s what will happen next:

  1. Our GitHub bots will run to check your changes.
    If they spot any issues you will see some error messages on this PR.
    Don’t hesitate to ask any questions if you’re not sure what these mean!

  2. In a few minutes, you’ll be able to see a preview of your changes on Vercel

  3. One or more of our maintainers will take a look and may ask you to make changes.
    We try to be responsive, but don’t worry if this takes a few days.

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
app/components/Package/WeeklyDownloadStats.vue (1)

204-204: Consider Math.round instead of Math.ceil for display values.

Using Math.ceil systematically biases displayed values upwards (e.g., 34,803,664.95734,803,665 happens to match, but 34,803,664.1 would also become 34,803,665). Since the goal is to hide fractional artefacts from smoothing/moving-average post-processing rather than to report an upper bound, Math.round would be more faithful to the underlying data.

♻️ Proposed refinement
-    value: Math.ceil(d?.value ?? 0),
+    value: Math.round(d?.value ?? 0),
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@app/components/Package/WeeklyDownloadStats.vue` at line 204, In
WeeklyDownloadStats.vue locate the mapping that sets value: Math.ceil(d?.value
?? 0) and replace Math.ceil with Math.round so the display values use rounding
instead of always rounding up (i.e., change to value: Math.round(d?.value ??
0)); keep the nullish fallback (d?.value ?? 0) intact so only the rounding
strategy changes.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@app/components/Package/WeeklyDownloadStats.vue`:
- Line 204: In WeeklyDownloadStats.vue locate the mapping that sets value:
Math.ceil(d?.value ?? 0) and replace Math.ceil with Math.round so the display
values use rounding instead of always rounding up (i.e., change to value:
Math.round(d?.value ?? 0)); keep the nullish fallback (d?.value ?? 0) intact so
only the rounding strategy changes.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: e9bbf48e-3e7e-4aff-84b5-65d5d31cf4e3

📥 Commits

Reviewing files that changed from the base of the PR and between cbcdc54 and 47bd16e.

📒 Files selected for processing (1)
  • app/components/Package/WeeklyDownloadStats.vue

@codecov
Copy link
Copy Markdown

codecov bot commented Apr 17, 2026

Codecov Report

❌ Patch coverage is 66.66667% with 1 line in your changes missing coverage. Please review.
✅ All tests successful. No failed tests found.

Files with missing lines Patch % Lines
app/components/Package/TrendsChart.vue 0.00% 0 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!

@graphieros
Copy link
Copy Markdown
Contributor

@ulrichstark

Thank you for your PR :)

This issue was already addressed in #2519 (sparkline) and #2550 (other charts).
However, I think the approach of rounding numbers directly @applyDataCorrection is a better one, if you want to rework your solution, I would be happy to merge it.

@graphieros graphieros marked this pull request as draft April 17, 2026 15:43
@ulrichstark
Copy link
Copy Markdown
Contributor Author

Hey @graphieros, thanks for the prompt review! Just reverted my first commit and made the change in applyDataCorrection by adding rounding (up) as last step. I hope this is what you meant. Enjoy your weekend!

@ulrichstark ulrichstark marked this pull request as ready for review April 17, 2026 20:25
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (2)
app/utils/chart-data-correction.ts (2)

85-95: Document the new rounding step in the function contract.

applyDataCorrection now also ceilings values, but the JSDoc still describes only moving average and smoothing. Please update it so callers know the returned values are integer-rounded.

Suggested documentation update
 /**
- * Applies moving average then smoothing in sequence.
+ * Applies moving average, smoothing, then ceiling-rounds values in sequence.
  */
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@app/utils/chart-data-correction.ts` around lines 85 - 95, Update the JSDoc
for applyDataCorrection to reflect the new final rounding step: mention that the
function applies a moving average (movingAverage), then smoothing (smoothing),
and finally ceilings values to integers (Math.ceil) on the value field of each
returned item; state that the returned array preserves items of type T but with
value rounded up to an integer. Edit the comment block immediately above the
export function applyDataCorrection to include this behaviour and an explicit
note that callers should expect integer-rounded values.

95-95: Add or update a test that covers the final ceiling step.

The new behaviour is central to this fix, but the related applyDataCorrection mock in test/unit/app/utils/chart-data-prediction.spec.ts returns data unchanged, so pipeline tests will not catch regressions in this integer-output contract.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@app/utils/chart-data-correction.ts` at line 95, The final Math.ceil rounding
step (result = result.map(d => ({ ...d, value: Math.ceil(d.value) }))) isn't
covered by tests because the applyDataCorrection mock in
test/unit/app/utils/chart-data-prediction.spec.ts returns data unchanged; add or
update a unit test to call applyDataCorrection (or run the full pipeline that
uses applyDataCorrection) and assert that output values are integers (use
Math.floor/=== or Number.isInteger) and reflect ceiling behaviour for fractional
inputs, or change the mock to mimic the ceiling transformation so pipeline tests
will fail if the ceiling step is removed; reference applyDataCorrection and the
mapping line to locate where to assert the integer-output contract.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@app/utils/chart-data-correction.ts`:
- Around line 85-95: Update the JSDoc for applyDataCorrection to reflect the new
final rounding step: mention that the function applies a moving average
(movingAverage), then smoothing (smoothing), and finally ceilings values to
integers (Math.ceil) on the value field of each returned item; state that the
returned array preserves items of type T but with value rounded up to an
integer. Edit the comment block immediately above the export function
applyDataCorrection to include this behaviour and an explicit note that callers
should expect integer-rounded values.
- Line 95: The final Math.ceil rounding step (result = result.map(d => ({ ...d,
value: Math.ceil(d.value) }))) isn't covered by tests because the
applyDataCorrection mock in test/unit/app/utils/chart-data-prediction.spec.ts
returns data unchanged; add or update a unit test to call applyDataCorrection
(or run the full pipeline that uses applyDataCorrection) and assert that output
values are integers (use Math.floor/=== or Number.isInteger) and reflect ceiling
behaviour for fractional inputs, or change the mock to mimic the ceiling
transformation so pipeline tests will fail if the ceiling step is removed;
reference applyDataCorrection and the mapping line to locate where to assert the
integer-output contract.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 9631dd62-a3c8-4154-8fab-a6551591f68d

📥 Commits

Reviewing files that changed from the base of the PR and between 47bd16e and 7881b72.

📒 Files selected for processing (1)
  • app/utils/chart-data-correction.ts

Copy link
Copy Markdown
Contributor

@graphieros graphieros left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ulrichstark

Perfect.
Prior changes applied higher up need to be reverted / adapted, now that the rounding is rooted:

  • TrendsChart.vue : https://github.com/npmx-dev/npmx.dev/pull/2550/changes : the rounding can be removed
  • SplitSparkline.vue : the maximumFractionDigits param can be removed from the composable call
  • WeeklyDownloadStats.vue: the maximumFractionDigits param can be removed from the composable call

@ulrichstark ulrichstark changed the title fix: round downloads to avoid fractions showing up when hovering WeeklyDownloadStats fix: round chart numbers in applyDataCorrection for consistent rounding Apr 18, 2026
@graphieros graphieros self-requested a review April 18, 2026 07:36
Copy link
Copy Markdown
Contributor

@graphieros graphieros left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 🌿

@graphieros graphieros added this pull request to the merge queue Apr 18, 2026
@ulrichstark
Copy link
Copy Markdown
Contributor Author

LGTM 🌿

Thanks for assisting on this change!

Does this mean the original issue way already fixed but not yet released to production? This would also explain that I failed to reproduce it locally, but could on production and therefore could only proof it using the devtools on the production site.

Merged via the queue into npmx-dev:main with commit b7f71a6 Apr 18, 2026
22 checks passed
@ulrichstark ulrichstark deleted the fix--round-downloads-to-avoid-fractions-showing-up-when-hovering-WeeklyDownloadStats branch April 18, 2026 07:42
@graphieros
Copy link
Copy Markdown
Contributor

graphieros commented Apr 18, 2026

Does this mean the original issue way already fixed but not yet released to production? This would also explain that I failed to reproduce it locally, but could on production and therefore could only proof it using the devtools on the production site.

Yes, it will be in production with the next release
In the meantime, as a contributor, I recommend you use https://main.npmx.dev/ as your daily driver :)

@ulrichstark
Copy link
Copy Markdown
Contributor Author

Does this mean the original issue way already fixed but not yet released to production? This would also explain that I failed to reproduce it locally, but could on production and therefore could only proof it using the devtools on the production site.

Yes, it will be in production with the next release In the meantime, as a contributor, I recommend you use https://main.npmx.dev/ as your daily driver :)

Ahhh perfect. Thank you very much once again!!

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.

2 participants