Markstream Migration

Markstream Migration

Use this skill when a repo already renders Markdown and the task is either to adopt Markstream safely or to upgrade an existing markstream-vue 1.x integration to 2.x.

Choose The Migration Route

Inspect package.json, the lockfile, imports, and renderer props before changing code.

• If the repo already depends on markstream-vue 1.x, read references/vue-1x-to-2x.md and follow Route B. Confirm the package dependency instead of routing only from shared names such as MarkdownCodeBlockNode or InternalParseOptions, which can also appear in other adapters.
• Otherwise, when replacing react-markdown, markdown-it, marked, or another renderer with a Markstream package, read references/adoption-checklist.md and follow Route A.
• If both apply, complete the 1.x to 2.x package and API upgrade first, then audit the separate renderer replacement as an adoption task.

Route A: Adopt Markstream From Another Renderer

1. Audit the repo's current renderer usage.
   • Search for markdown renderers, plugin chains, raw HTML handling, security props, and custom renderers.
   • List every call site that will be touched.
2. Classify the migration.
   • direct: simple string-in renderer swap.
   • renderer-custom: custom renderers but limited parser work.
   • plugin-heavy: remark, rehype, markdown-it, or other transform-heavy pipelines.
   • security-heavy: allow or deny lists, URL rewriting, sanitization, or raw HTML policies.
3. Swap the renderer first.
   • Introduce the correct Markstream package and CSS.
   • Import Markstream CSS through the package CSS subpath; do not rely on the renderer import to inject styles.
   • Preserve user-visible behavior before adding richer Markstream-only features.
   • Audit whether the old renderer allowed broad raw HTML or Mermaid loose-mode HTML labels before claiming parity.
4. Migrate custom renderers.
   • Convert built-in node renderers into scoped node-type overrides.
   • In React, prefer renderer-local streamingComponents for parser-backed tags and htmlComponents for sanitized HTML-prop components; use setCustomComponents for built-in node overrides or shared compatibility registration.
   • In Svelte or Angular, prefer the renderer-local customComponents input when the mapping does not need shared registration.
   • For trusted tag-like content, prefer customHtmlTags.
   • Use parseOptions.preTransformTokens, postTransformTokens, or postTransformNodes only when the old pipeline truly requires token or AST transforms.
5. Review gaps honestly.
   • Do not claim 1:1 parity where none exists.
   • Call out parser, plugin, security, or HTML behavior that still needs manual review.
6. Consider renderer mode and smooth streaming before jumping to nodes.
   • For Vue 3, choose mode="chat" for AI/SSE output, mode="docs" for rich document surfaces, and mode="minimal" for lightweight non-chat surfaces.
   • If the app streams content and only needs pacing, smooth-streaming="auto" (the default) handles it without requiring nodes.
   • Move to nodes only when the app needs custom AST control, worker preparsing, or high-frequency structural updates.
   • In Vue 3 (including Nuxt), smooth-streaming controls output pacing and fade controls opacity; they can be enabled together. mode="chat" keeps fade=false as a lightweight default. Add fade when gradual text reveal is desired; keep it off when animation cost matters more. Do not carry a legacy :fade="!isStreaming" binding into a Vue 3 migration unless the host wants that policy.
   • Streaming vs recovering history: when migrating a chat UI, keep mode="chat" on the same chat row and switch pacing/animation props instead. Vue 3 streaming: mode="chat", final, and optional fade. Vue 3 completed chat history: keep mode="chat", use :smooth-streaming="false" when pacing is unnecessary, and choose fade independently. Use mode="docs" only for separate rich document surfaces.
7. Validate and summarize.
   • Run the smallest relevant tests or build.
   • Report direct mappings, TODOs, and remaining verification work.