feat(blog): rasterise a post's diagrams automatically when the copy buttons render - #167
Merged
Merged
Conversation
…uttons render The copy-for-LinkedIn payload only swaps SVG diagrams for inlined PNGs that rasterise-diagrams.mjs has already written to tmp/diagrams/<post-dir>/. In a fresh checkout or worktree, or after a post folder is renamed on publish, there are none, and the copy silently falls back to SVGs that LinkedIn drops. That is what happened copying Agentic Security Part 1. CopyIssue now checks whether any of the post's PNGs are missing or older than their SVG and, if so, runs the rasteriser for just those. It runs as a child process because Playwright cannot be loaded through Vite's module runner; the cheap staleness check lives in diagram-cache.mjs so the component never pulls Playwright in. First render of a post costs ~3s, later ones nothing extra. Dev-only, as before. Drops the TODO entry this resolves.
Visual parity — light theme ☀️Every captured route is pixel-identical to the merge base across 1440x1000 (40 routes) and 420x900 (40 routes). Informational: label the PR |
Visual parity — dark theme 🌙Every captured route is pixel-identical to the merge base across 1440x1000 (40 routes) and 420x900 (40 routes). Informational: label the PR |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The dev-only copy buttons now render any missing or outdated diagram PNGs themselves, so the LinkedIn copy of a blog post can't quietly fall back to SVGs.
This bit on Agentic Security Part 1 today. The copy payload inlines PNGs from
tmp/diagrams/<post-dir>/, but they only existed if someone had runrasterise-diagrams.mjsin that checkout. Renaming the folder on publish orphaned them too. So all 13 diagrams went into the clipboard as SVGs, and LinkedIn dropped them.CopyIssuenow checks the post's SVGs against their PNGs by mtime. When any are missing or stale, it runs the rasteriser for only those, as a child process: I tried importing it directly first, and Vite's module runner fails on Playwright's CommonJS entry (module is not defined). The cheap check is in a newdiagram-cache.mjs, so the component never loads Playwright.Verified on a dev server in a fresh worktree with no
tmp/diagrams. The first request for Part 1 took 3.1s and embedded all 13 PNGs, counted as 26 because the LinkedIn and newsletter payloads each carry them. The second request took 0.8s. After touching one SVG, only that diagram was re-rendered.The weakness: the first render of a post with many diagrams blocks for a few seconds while Chromium starts. It's dev-only and happens once per change, so I didn't make it async.
This also removes the TODO entry about renamed folders orphaning their diagrams, since that gap is now closed. The neighbouring TODO point is still open, and today's paste is the first real test of it: whether LinkedIn accepts a pasted data-URI image at all has never been verified.