Using and writing plugins
Plugins extend one stage of Core's content pipeline. Choose the stage that owns the behavior you want to change:
Core includes common Markdown syntax, repair, HTML handling, and streaming features. Each guide ends with its built-in plugins. Start by configuring one; write a plugin when you need another behavior.
Configure a preset
Plugin inputs accept three forms: a plugin list, a configuration object keyed by plugin name, or [pluginList, configObject]. In S, use the tuple form for a static configuration object:
Pass repairs alongside text and build when creating Core. This hides unfinished images while keeping the other presets.
You can also configure a plugin by class:
Existing preset classes keep their place in the list and receive the new options. New plugin classes are added. A keyed configuration overrides options from a class tuple when both are present.
RemarkConfigs,RehypeConfigs,RepairConfigs, andMapperConfigsare provided by the preset type declarations loaded with Core. You do not need to import these names separately.
Disable or reorder a plugin
All four categories accept disabled and priority:
This keeps ordinary Markdown newlines instead of turning them into hard line breaks. Smaller priority numbers run first within a category; equal values keep declaration order.
Write a plugin
Remark and rehype plugins adapt unified plugins. Repair plugins visit and update Markdown AST nodes. Mappers use Stative to produce a changing sequence of HAST blocks.
Each guide includes a declaration and shows how to register it:
Pass plugin classes or mapper functions; Core manages their lifecycle. Keep per-run data inside the transform or state flow so one declaration can serve multiple documents.
Import presets from
/remark,/rehype,/repair, or/mapper. The@fluxdown/core-presetspackage has no root entry point.