You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The shared markdown renderer's inline-link regex in website/modules/blog/utils/render-post.ts (/\[([^\]]+)\]\(([^)]+)\)/) stops the URL capture at the first ). A URL that legitimately contains a closing paren, e.g. [Ruby](https://en.wikipedia.org/wiki/Ruby_(programming_language)), is truncated to https://en.wikipedia.org/wiki/Ruby_(programming_language, so both the emitted href and (after #857) the external-vs-internal new-tab decision run on the wrong URL.
Pre-existing (predates the outbound-links change in #857); surfaced during that PR's review. Low real-world impact today because all repo-authored blog/compare markdown uses paren-free URLs, but it will silently corrupt the first Wikipedia-style link anyone writes.
Design / approach
Handle balanced parens in the URL portion (CommonMark permits nested balanced parens in the destination), or at minimum accept a single level of nested (...). A pragmatic fix is a small manual scan of the destination that tracks paren depth instead of the greedy [^)]+. Keep it dependency-free (the renderer is intentionally a small regex-based util, no markdown library).
Implementation notes (for the implementing agent)
Where: website/modules/blog/utils/render-post.ts, the inline() function, the link replace() on the /\[([^\]]+)\]\(([^)]+)\)/ regex.
Landmine: inline() first &<>-escapes the whole string, then runs the link regex; keep that ordering. feat: link compared frameworks from the /compare pages #857 added %22 href-escaping and an external/new-tab branch on the SAME captured URL, so whatever fix lands must feed the full (untruncated) URL into both.
Tests: add a case to website/test/ssr/compare-ssr.test.ts (or a blog render test) for a URL with a nested ).
No em-dashes / invariant-11 punctuation in new prose.
Acceptance criteria
[t](https://host/a_(b)) renders href="https://host/a_(b)" (full URL, not truncated).
The external/new-tab decision uses the full URL.
Test covers a paren-containing URL, with a counterfactual.
Problem
The shared markdown renderer's inline-link regex in
website/modules/blog/utils/render-post.ts(/\[([^\]]+)\]\(([^)]+)\)/) stops the URL capture at the first). A URL that legitimately contains a closing paren, e.g.[Ruby](https://en.wikipedia.org/wiki/Ruby_(programming_language)), is truncated tohttps://en.wikipedia.org/wiki/Ruby_(programming_language, so both the emittedhrefand (after #857) the external-vs-internal new-tab decision run on the wrong URL.Pre-existing (predates the outbound-links change in #857); surfaced during that PR's review. Low real-world impact today because all repo-authored blog/compare markdown uses paren-free URLs, but it will silently corrupt the first Wikipedia-style link anyone writes.
Design / approach
Handle balanced parens in the URL portion (CommonMark permits nested balanced parens in the destination), or at minimum accept a single level of nested
(...). A pragmatic fix is a small manual scan of the destination that tracks paren depth instead of the greedy[^)]+. Keep it dependency-free (the renderer is intentionally a small regex-based util, no markdown library).Implementation notes (for the implementing agent)
website/modules/blog/utils/render-post.ts, theinline()function, the linkreplace()on the/\[([^\]]+)\]\(([^)]+)\)/regex.inline()first&<>-escapes the whole string, then runs the link regex; keep that ordering. feat: link compared frameworks from the /compare pages #857 added%22href-escaping and an external/new-tab branch on the SAME captured URL, so whatever fix lands must feed the full (untruncated) URL into both.website/test/ssr/compare-ssr.test.ts(or a blog render test) for a URL with a nested).Acceptance criteria
[t](https://host/a_(b))rendershref="https://host/a_(b)"(full URL, not truncated).