Deprecated API

Vue 3 Rendering | Home

Core parsing API is stable. The items below are transitional utility and ambient-state APIs. Most of them are still exported from the package root; withCreateId only survives as a compatibility helper in a deep module path and is not exported from the root entry point.

---

In a nutshell

Old code used module-level implicit state (withSyntax, withCreateId, etc.). New code uses DslContext + ParseOptions for explicit passing. A few redundant handler factories are also replaced by more general ones.

Old way (implicit state)             New way (explicit)
┌──────────────────────┐          ┌──────────────────────┐
│ withSyntax(syntax,   │    →     │ createParser({        │
│   () => parse(...))  │          │   syntax, handlers    │
│                      │          │ })                    │
│ resetTokenIdSeed()   │    →     │ createId:             │
│                      │          │   createEasyStableId()│
└──────────────────────┘          └──────────────────────┘

---

Timeline

Not removed before September 2026. Warnings suppressed when NODE_ENV=production.

---

Deprecated list

Deprecated	Exported from root?	Use instead	Warns?	Why deprecated
withSyntax	Yes	DslContext / createParser({ syntax })	Yes	Module-level implicit state
getSyntax	Yes	DslContext	Yes	Same
withTagNameConfig	Yes	ParseOptions.tagName	Yes	Same
withCreateId	No	DslContext	Yes	Same; deep-path compatibility only
resetTokenIdSeed	Yes	DslContext.createId	Yes	Module-level ID counter
createPipeBlockHandlers	Yes	createPipeHandlers + block	No	Redundant
createPipeRawHandlers	Yes	createPipeHandlers + raw	No	Redundant
createPassthroughTags	Yes	Empty handler objects / app-local helper	No	The library no longer recommends packaging implicit fallback as a public helper
ParseOptions.mode	N/A	Just remove it	No	Only one value

Note: “Deprecated” here describes the compatibility-layer semantics, not whether every symbol is still available from import {...} from "yume-dsl-rich-text". The compatibility APIs still exported from the root entry point are: withSyntax, getSyntax, withTagNameConfig, resetTokenIdSeed, createPipeBlockHandlers, createPipeRawHandlers, and createPassthroughTags. withCreateId still exists internally and still warns, but it is not part of the root public export surface.

---

Migration examples

withSyntax → createParser

// Before
withSyntax(customSyntax, () => {
    const tokens = parseRichText("...", { handlers });
});

// After
const dsl = createParser({ syntax: createSyntax(customOverrides), handlers });
const tokens = dsl.parse("...");

resetTokenIdSeed → createEasyStableId

// Before
resetTokenIdSeed();
const tokens = parseRichText("...", { handlers });

// After
const dsl = createParser({ handlers, createId: createEasyStableId() });
const tokens = dsl.parse("...");

createPipeBlockHandlers → createPipeHandlers

// Before
const handlers = createPipeBlockHandlers(["info", "warning"]);

// After
const handlers = createPipeHandlers({
    info: {
        block: (args, content, ctx, rawArg) => ({
            type: "info",
            arg: rawArg,
            args: args.parts.map((_, i) => args.text(i)),
            value: content,
        }),
    },
    warning: {
        block: (args, content, ctx, rawArg) => ({
            type: "warning",
            arg: rawArg,
            args: args.parts.map((_, i) => args.text(i)),
            value: content,
        }),
    },
});

createPassthroughTags → empty handler objects / local helper

// Before
const handlers = createPassthroughTags(["bold", "italic"]);

// After
const handlers = {
    bold: {},
    italic: {},
};

createPassthroughTags does not actually mean “create simple inline handlers”. Its real behavior is to register empty handlers and let the parser's internal default materialization / fallback logic produce the final token shape.

That means it is not equivalent to createSimpleInlineHandlers:

• createSimpleInlineHandlers installs an explicit inline handler that always returns {type, value}
• createPassthroughTags relies on implicit fallback

If older code intentionally depends on that implicit fallback, the recommended migration is to keep that behavior in application code with a tiny local helper, or just write the empty handlers directly, instead of replacing it with a different library helper that carries different semantics.

This is not a vague replacement. The actual behaviour is:

• bold: {} gives inline form the default output shape: { type: tagName, value: materializedChildren }
• it does not auto-declare raw or block form
• without raw / block methods, those forms still degrade back to source text
• if the same tag should support inline plus raw/block, write inline + raw / block explicitly