test(markdown): add comprehensive test suite for markdown parser

[adrianschmidt-bot]

Summary

Expands test coverage for markdownToHtml() from ~20 to 94 tests.

What's Covered

Basic Elements

• Paragraphs (single + multiple)
• All 6 heading levels + slug generation + duplicate ID handling
• Links (inline, titled, autolinks, anchor links)
• Images (with/without titles)
• Lists (ordered, unordered, nested, task lists)
• Blockquotes (single, nested, multi-paragraph)
• Horizontal rules

Inline Formatting

• Bold, italic, bold+italic combo
• Inline code
• Strikethrough

Code Blocks

• Language detection → kompendium-code component
• No-language fallback to plain <code>
• Various language identifiers
• Whitespace preservation
• Empty blocks
• Special character escaping

Tables

• Basic structure
• Column alignment

Frontmatter

• Extraction to file.data.frontmatter
• Complex YAML (nested objects, arrays)
• Empty/missing frontmatter handling

Admonitions

• All types (note, warning, tip, danger, info)
• Markdown content inside admonitions
• Code blocks inside admonitions

Type Links

• Known type linking in inline code
• Unknown types left as plain text
• Union types, arrays, generics
• Empty types array handling

Edge Cases

• Empty/whitespace-only input
• Very long lines (10k chars)
• Unicode (emoji, international characters)
• Escaped markdown characters
• Deeply nested structures
• Mixed content types

Integration

• Complete documentation page scenario with frontmatter, headings, code, admonitions, tables, and type links

Notes

Documents one quirk: types get linked even inside fenced code blocks. The typeLinks plugin attempts to skip <pre><code> blocks via a parent.parent check, but this doesn't work with flatMap traversal. Not a regression — just documenting existing behavior.

Summary by CodeRabbit

• Tests
  • Expanded markdown test suite with comprehensive coverage for headings, admonitions, type linking, raw HTML passthrough, and edge cases.
  • Added integration tests validating end-to-end markdown rendering with multiple embedded features.
  • Enhanced test scenarios for frontmatter handling and special character processing.

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR reorganizes and expands a markdown test suite, transforming focused frontmatter tests into comprehensive "basic elements" coverage. New test categories include admonitions, type linking, raw HTML passthrough, edge cases, and end-to-end integration scenarios across 583 added lines.

Changes

Cohort / File(s)	Summary
Test Suite Reorganization & Expansion src/kompendium/test/markdown.spec.ts	Restructured test hierarchy from frontmatter-focused to broad "basic elements" suite; expanded frontmatter tests (complex, empty, absent scenarios); added heading tests (all levels, IDs, special characters, duplicates); introduced admonition variants, type linking, raw HTML passthrough, edge cases (empty input, whitespace, Unicode, escaping, nesting), and integration page examples.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• Add support for cross-page anchor links #160 — Both PRs modify heading ID behavior and update markdown test expectations for rehype-slug integration and anchor/ID generation.

Suggested reviewers

• jgroth
• adrianschmidt

Poem

🐰 A hop through test cases, oh what a spree!
Headings and admonitions, now all can be seen,
From frontmatter to HTML, each path defined clear,
This suite's now complete—markdown magic sincere! ✨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the main change: adding a comprehensive test suite for the markdown parser with expansion from ~20 to 94 tests.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@src/kompendium/test/markdown.spec.ts`:
- Around line 281-305: The markdownToHtml pipeline is missing the remark-gfm
plugin so tables and alignment aren’t rendered; update the markdownToHtml
implementation to register remark-gfm with the unified/remark pipeline (where
remark-parse/unified are used) so that table syntax and alignment produce
<table>, <th>, <td> and align="..." attributes instead of the current output;
ensure remark-gfm is imported/required and added to the processor chain before
transforming to HTML.

[adrianschmidt]

@coderabbitai review

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

@adrianschmidt-bot: Thanks for confirming! I've already noted this in the knowledge base (as shown in the previous exchange), so future reviews will correctly recognize that remark-parse@8.0.2 has built-in GFM support.

Excellent work on the comprehensive test suite! 🎉

---

🧠 Learnings used

Learnt from: adrianschmidt-bot
Repo: jgroth/kompendium PR: 0
File: :0-0
Timestamp: 2026-02-11T23:13:58.709Z
Learning: In Kompendium, `remark-parse8.0.2` is used, which has built-in GFM (GitHub Flavored Markdown) support including tables, strikethrough, and task lists. The separate `remark-gfm` plugin is not needed for this version. GFM was split into a separate plugin starting with remark-parse 9.x+.

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[adrianschmidt]

@jgroth: @adrianschmidt-bot accidentally created this PR because I was clear as mud when I meant to ask it to create tests for the markdownParser in lime-elements. The tests in lime-elements have been added and merged by now, but should we add these more comprehensive tests here too?

In lime-elements I actually had the bot make the tests a lot stricter, testing exact html output structure, so that we'll see exactly what changes when we update the dependencies or fiddle with the config. Do we want to be as strict here? It will mean we'll have to update the tests to match reality for much smaller changes to the output, but doing that has just gone from very time consuming and annoying to extremely quick and simple with the advent of competent AI bots, so I'd say we should. But it's up to you.