fix: remove up to the fence indentation from each content line

[Kjubikstronk]

Marked version: 18.0.11 (53cb13f)

Markdown flavor: CommonMark

Description

CommonMark removes up to N spaces from each line of a fenced code block when the opening fence is indented by N. indentCodeCompensation only strips a line that is indented at least N:

if (indentInNode.length >= indentToCode.length) {
  return node.slice(indentToCode.length);
}

return node;

So a line indented less than the fence keeps all of its indentation instead of losing what it has.

Expectation

For example 133, a fence indented by three spaces:

   ```
   aaa
    aaa
  aaa
   ```

gives aaa\n aaa\naaa\n. The four space line keeps one, the two space line keeps none.

Result

aaa\n aaa\n aaa\n. The four space line is handled correctly, the two space line keeps both of its spaces.

What was attempted

node.slice(Math.min(indentInNode.length, indentToCode.length)) covers both directions, so the branch goes away rather than gaining a case.

I diffed the exact-match failure set across the whole spec before and after: 133 moves to passing and nothing else changes, in both the CommonMark and GFM runs.

This is the same blind spot as #4073. htmlIsEqual builds @markedjs/html-differ with only ignoreSelfClosingSlash and ignoreComments, so ignoreWhitespaces stays at its default of true. Whitespace inside pre/code is significant, so 133 was already reported as passing and carries no shouldFail flag. The spec suite therefore cannot protect this fix either, which is why the tests below assert exact output.

A correction to something I wrote in #4073 and in #4050, since it is wrong and has been repeated since: I described example 318 as a lexer bug. It is not. Code token text has no single convention, '```\nb\n```' gives "b" while ' b\n' gives "b\n", and Renderer.code's strip-then-append exists to reconcile that. The token is correct under marked's own convention and the renderer is where the trailing blank lines are lost. I tried the obvious fix, moving the newline inside the fences capture group and reducing the renderer to const code = text. It fixes 126, 130, 144, 237 and 318, and breaks 117, 128, 211, 236, 253 and 272, because indented code and fenced code inside a blockquote genuinely have no trailing newline in the token and rely on the renderer supplying it. Fixing 318 properly means agreeing one convention across every code token path, which changes token.text for fenced code and is a decision for the team rather than a drive-by PR.

Contributor

• Test(s) exist to ensure functionality and minimize regression (if no tests added, list tests covering this PR); or,
• no tests required for this PR.
• If submitting new feature, it has been documented in the appropriate places.

Two tests in test/unit/marked.test.js under fenced code block indentation. The first fails without the change; the second, a line indented more than the fence, passes either way as a control. Full spec suite (1789) and unit suite (193) pass.

Committer

In most cases, this should be a different person than the contributor.

• CI is green (no forced merge required).
• Squash and Merge PR following conventional commit guidelines.

[vercel]

@Kjubikstronk is attempting to deploy a commit to the MarkedJS Team on Vercel.

A member of the Team first needs to authorize it.

[UziTech]

move specs to test/specs/new with renderExact

[Kjubikstronk]

Moved to test/specs/new/fence_indent_stripping.md with renderExact in 6713747, and marked.test.js is untouched again.

Both cases are in the one fixture, the three space fence with a line indented less than it, and a line indented more that keeps the remainder. Reverting indentCodeCompensation fails it.

[vercel]

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

Project	Deployment	Actions	Updated
marked-website	Ready	Preview	Sep 3, 2026 3:49am UTC

[UziTech]

Thanks! 💯