Options determining how a Notion page transforms into an object of metadata (front matter) and a string of HTML.
Maps a page property in Notion to a key in the generated object of
metadata. The name option must match the name of the page property (i.e.
database column) in Notion. The property's value is then placed under the
key or path specified by rename (which defaults to the value in name).
When rename is specified as an array of strings, then the property is
nested under the specified keys.
For example, if we specify name: "SEO description" together with
rename: ["seo", "description"], then the value of the "SEO description" field in Notion can be accessed using the metadata by accessing the nested seo.description` property.
formatters: { inline?: InlineFormatters; block?: BlockFormatters; }
The formatters to use for both inline text (Notion calls this "rich text") and blocks.
For inline formatting, sensible fallbacks are set in an attempt to generate somewhat semantic HTML by default. However, each type can be overwritten to allow for completely custom rich text stringification. Technically, it doesn't even need to stringify to HTML.
Due to limitations in the Notion API, it is impossible to support both
text colors as well as background colors for text. As such, text colors
are not supported. The color formatter refers to text background
colors only. Text colors are ignored, but using them can break
the processing of specified background colors.
For block formatting, there are types that do not have a fallback, because there is not always a default that makes sense for the majority of users. When the builder encounters a block of a type that is not specified and does not have a fallback, a warning is logged and the block (including all of its children) are ignored. To prevent this, you must specify your own block formatter of the type in question.