Skip to content

fix(sync): never rewrite inside inline code spans, and repair what it broke - #132

Merged
adnaan merged 1 commit into
mainfrom
fix/sync-inline-code-spans
Aug 2, 2026
Merged

fix(sync): never rewrite inside inline code spans, and repair what it broke#132
adnaan merged 1 commit into
mainfrom
fix/sync-inline-code-spans

Conversation

@adnaan

@adnaan adnaan commented Aug 2, 2026

Copy link
Copy Markdown
Contributor

This fixes a bug I introduced in #130 that corrupted five published pages. Supersedes #131.

What broke

RewriteRelative skipped fenced code blocks but not inline code spans. Go generic call syntax inside one — `AssertPureState[T](t)` — contains the exact ](...) shape a markdown link does, so the rewriter resolved (t) as a relative path. Live on the site right now:

AssertPureState[T](https://github.com/livetemplate/livetemplate/blob/v0.22.0/docs/references/t)

Five places: reference/session.md (×3), reference/limitations.md, guides/ephemeral-components.md.

The #130 plan flagged this exact risk — "over-eager rewriting mangles code blocks" — and the guard I wrote covered only the fenced case. The inline case is the one that actually occurs in this corpus.

The fix

rewriteOutsideCodeSpans splits a line on backticks and rewrites only even-indexed (prose) segments.

A line with an odd number of backticks cannot have its spans paired, and the parity is wrong from the stray one onward — code would land on an "outside" index and be rewritten anyway. Those lines are now left entirely alone. That costs a genuine link on a malformed line staying as upstream wrote it, which is recoverable; mangling documented code is not.

Worth stating plainly: my first version of that comment claimed the unbalanced case already erred toward safety. It did not — the test I wrote to assert it failed, which is why the explicit count check exists rather than relying on parity.

Regression tests

Three, all of which fail against the previous implementation:

  • inline span alongside a real link on the same line
  • multiple spans interleaved with multiple links
  • the unbalanced-backtick case

19 RewriteRelative/LinkRewriter tests pass.

Also carries the v0.23.0 sync

Re-syncing at v0.23.0 is what repairs the five pages, and it brings the release's own content with it — the Async/{{.lvt.Pending}} guide rewrite, the Validate reference section, and the lvt-el overlay documentation from livetemplate#530.

That makes this a strict superset of #131, which carries the same content through the unfixed rewriter. Close #131 in favour of this.

Verification

  • Zero corrupted spans remain; zero relative links introduced into content/ (the three the diff shows are fixture strings in sync_test.go)
  • source_ref now v0.23.0 across mirrored pages
  • tinkerdown validate content/: 98/98
  • go build ./..., go vet ./cmd/... clean

🤖 Generated with Claude Code

https://claude.ai/code/session_01QzC2djPjPHkNJgPzFpMX7v

… broke

I shipped this in #130 and it corrupted five published pages.

RewriteRelative skipped fenced code blocks but not inline code spans, and Go
generic call syntax inside one — `AssertPureState[T](t)` — contains the exact
](...) shape a markdown link does. The rewriter resolved (t) as a relative
path, so documented code rendered on the live site as:

  AssertPureState[T](https://github.com/livetemplate/livetemplate/blob/v0.22.0/docs/references/t)

in reference/session.md (three places), reference/limitations.md and
guides/ephemeral-components.md. My own plan for #130 flagged exactly this risk
— "over-eager rewriting mangles code blocks" — and the guard I wrote covered
only the fenced case.

rewriteOutsideCodeSpans splits a line on backticks and rewrites only the
even-indexed (prose) segments. A line with an ODD number of backticks cannot
have its spans paired, and the parity is wrong from the stray one onward, so
code would land on an "outside" index and be rewritten anyway — those lines are
now left entirely alone. That costs a genuine link on a malformed line staying
as upstream wrote it, which is recoverable; mangling documented code is not.

The first version of that comment claimed the unbalanced case already erred
toward safety. It did not — the test written to assert it failed, which is why
the count check exists.

Three regression tests: an inline span alongside a real link, multiple spans on
one line, and the unbalanced case.

Also re-syncs at v0.23.0, which repairs all five pages and brings down the
release's own content — the Async/Pending guide rewrite, the Validate reference
and the lvt-el overlay section. Verified: zero corrupted spans remain, zero
relative links in content, tinkerdown validate 98/98.

Supersedes the automated sync PR #131, which carries the same v0.23.0 content
but through the unfixed rewriter.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QzC2djPjPHkNJgPzFpMX7v
@adnaan
adnaan merged commit fd58ce5 into main Aug 2, 2026
4 checks passed
@adnaan
adnaan deleted the fix/sync-inline-code-spans branch August 2, 2026 03:10
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.

1 participant