Keep ImgBot off the favicon, and document that re-rendering undoes it - #6
Conversation
ImgBot minified favicon.svg, which is hand-written and carries comments naming the brand colours and the size the glyph is drawn to read at. Saving 300 bytes is not worth losing those, so restore the source and add .imgbotconfig to skip that one file. The 16 cards, where the actual 1.1 MB is, stay optimised. The trap worth writing down: og-render.mjs regenerates at Chrome's compression, so running it after ImgBot has been through inflates public/og from 2.6 MB back to 3.7 MB and dirties all sixteen files. Verified, and noted in the script.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Reviewer's guide (collapsed on small PRs)Reviewer's GuideRestores the hand-authored favicon SVG while configuring ImgBot to ignore it, and documents the interaction between ImgBot and the og image rendering script so reviewers understand why re-rendering changes file sizes and touches all card images. Flow diagram for og image rendering and ImgBot recompression interactionflowchart LR
dev[Developer runs og-render.mjs]
script[og-render.mjs uses execFile to drive headless Chrome]
chrome[Headless Chrome renders 16 PNG cards]
bigpngs[PNG cards at ~3.7 MB total]
commit[Commit rendered PNGs]
imgbot[ImgBot PR losslessly recompresses PNGs]
smallpngs[PNG cards at ~2.6 MB total]
dev --> script
script --> chrome
chrome --> bigpngs
bigpngs --> commit
commit --> imgbot
imgbot --> smallpngs
rerun[Re-run og-render.mjs after ImgBot]
inflate[PNG cards return to ~3.7 MB and all 16 files change]
smallpngs --> rerun
rerun --> inflate
Flow diagram for favicon handling with ImgBot configurationflowchart LR
favicon[Hand-authored public/favicon.svg with brand colour comments]
config[.imgbotconfig excludes favicon.svg]
imgbot[ImgBot image optimiser]
cards[16 card images in public/og]
favicon --> config
config --> imgbot
imgbot -->|skips| favicon
imgbot -->|optimises| cards
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
Warning Review limit reached
Next review available in: 55 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (2)
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. Comment |
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've found 1 issue
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location path="scripts/og-render.mjs" line_range="16-21" />
<code_context>
* nobody: no npm package to install, and it resolves system fonts the same way
* the browser preview does, so what was approved is what gets written.
+ *
+ * NOTE: the committed PNGs have been through ImgBot, which losslessly recompresses
+ * them by about 30% (2.6 MB rather than 3.7 MB). Chrome does not compress that
+ * hard, so re-running this rewrites all sixteen at the larger size and shows up
+ * as a diff touching every card. That is expected. Commit it and let ImgBot
+ * shrink them again in its own PR, or run them through an optimiser yourself.
+ * Chrome's output is otherwise deterministic: rendering without changing a card
+ * produces byte-identical files.
*/
</code_context>
<issue_to_address>
**issue:** Determinism claim may not hold across Chrome/OS/font changes.
This note assumes Chrome always produces byte-identical PNGs, which may not hold across different Chrome versions, OS/font configurations, or hardware acceleration settings. Consider scoping the claim (e.g., "on the same machine with the same Chrome version and font set") or explicitly noting that environment changes can cause diffs even when card content is unchanged.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| * NOTE: the committed PNGs have been through ImgBot, which losslessly recompresses | ||
| * them by about 30% (2.6 MB rather than 3.7 MB). Chrome does not compress that | ||
| * hard, so re-running this rewrites all sixteen at the larger size and shows up | ||
| * as a diff touching every card. That is expected. Commit it and let ImgBot | ||
| * shrink them again in its own PR, or run them through an optimiser yourself. | ||
| * Chrome's output is otherwise deterministic: rendering without changing a card |
There was a problem hiding this comment.
issue: Determinism claim may not hold across Chrome/OS/font changes.
This note assumes Chrome always produces byte-identical PNGs, which may not hold across different Chrome versions, OS/font configurations, or hardware acceleration settings. Consider scoping the claim (e.g., "on the same machine with the same Chrome version and font set") or explicitly noting that environment changes can cause diffs even when card content is unchanged.
There was a problem hiding this comment.
Pull request overview
This PR restores a human-readable, commented favicon.svg while preventing ImgBot from re-minifying it, and adds documentation explaining why rerunning the OG image renderer will temporarily inflate and rewrite committed PNG assets.
Changes:
- Restore
public/favicon.svgto the commented, hand-authored source for maintainability. - Add
.imgbotconfigto exclude the favicon from ImgBot optimisation while keeping OG image optimisation intact. - Document in
scripts/og-render.mjsthat rerendering produces larger PNGs until ImgBot recompresses them again.
Reviewed changes
Copilot reviewed 2 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| scripts/og-render.mjs | Adds documentation about expected diffs/size changes when rerendering OG cards after ImgBot recompression. |
| public/favicon.svg | Reverts favicon to the readable, commented version with brand/color notes. |
| .imgbotconfig | Configures ImgBot to ignore the favicon so the handcrafted SVG stays intact. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Follow-up to #5.
public/favicon.svgto its commented source and adds.imgbotconfigto skip that one file. It is hand-written, and the comments name the brand colours and the size the glyph is drawn to read at, which is worth more than the 300 bytes. The 16 cards, where the real 1.1 MB saving is, stay optimised.og-render.mjs: re-rendering after ImgBot inflatespublic/ogfrom 2.6 MB back to 3.7 MB and dirties all sixteen files, because Chrome does not compress as hard. Verified rather than assumed.No version bump, nothing user-facing.
Summary by Sourcery
Restore the handcrafted favicon SVG while excluding it from ImgBot optimisation, and document the impact of rerunning the OG image renderer after ImgBot recompression.
Enhancements:
Documentation:
Chores: