4 Commits (feat/not-found)

Author	SHA1	Message	Date
Divyansh Singh	09f9672ee1	fix: harden eager frontmatter interpolation (#5413) ... Co-authored-by: Claude Fable 5 <noreply@anthropic.com>	2 weeks ago
Divyansh Singh	5a368d3198	chore: format codebase and remove unused icons	3 weeks ago
Divyansh Singh	6a337efece	feat(markdown)!: rebase relative urls in included files ... Relative image and link urls inside included markdown files now resolve from the included file's location instead of from the page including it, so a partial can link to its neighbors regardless of who includes it. This matches @mdit/plugin-include, whose resolveImagePath and resolveLinkPath are on by default as well. Included content is wrapped in marker comments during expansion; hidden html_block rules maintain a per-render directory stack and the image and link_open renderer wrappers rebase '.'-prefixed urls against its top, so nested includes resolve correctly and urls outside included content are untouched. The markers are separated by blank lines so an adjacent html block cannot absorb them, and are only emitted for directives on a line of their own outside fenced blocks, so they can never reach the output. The include plugin registers after the image and link plugins so that rebasing runs before their url handling. BREAKING CHANGE: relative urls in included markdown files resolve against the included file rather than the including page. Partials written for one specific location may need their links updated, or markdown.include.rebaseRelativeUrls set to false to keep resolving them from the including page. Absolute and external urls are unaffected. Note that the marker comments shift the line numbers reported for dead links following an include, which already pointed into the include-expanded source rather than the original file. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	1 month ago
Divyansh Singh	0e50d756f5	feat(markdown)!: rewrite include processing as a markdown plugin ... Moves <!-- @include: --> expansion out of markdownToVue and the local search plugin into an include plugin registered on the renderer, which wraps renderAsync and expands includes whenever the env carries a file path. createMarkdownRenderer users and createContentLoader with render or excerpt enabled now get includes expanded too (previously the directives silently came through unexpanded), and the expansion is reachable from the public API without exporting the helper (#4838). Region selection uses the region engine (all same-named regions concatenate, matched across comment styles), frontmatter of markdown files is stripped before locating regions and headings so both share one coordinate space, and the region suffix is anchored to the end of the include path, so paths containing # now work. Files reached by a failed render are still reported, so that creating a missing snippet or include recovers the page instead of requiring an edit of the including file. BREAKING CHANGES: - a missing region or heading anchor now throws instead of silently including the whole file, and out-of-bounds or inverted ranges throw instead of clamping; markdown.include.silent logs a warning and expands to nothing instead - markdown.include is a new option; false disables include processing - custom search _render functions receive the raw source (sync md.render does not expand includes; use renderAsync) - the include-expanded source is exposed as env.src Co-authored-by: Miroma <its.miroma@proton.me> Co-authored-by: Naloam <110604855+Naloam@users.noreply.github.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	1 month ago