1 | import type {Value} from 'vfile'
|
2 | import type {CompileResults} from './lib/index.js'
|
3 |
|
4 | export type {
|
5 | // `CompileResultMap` is typed and exposed below.
|
6 | CompileResults,
|
7 | Compiler,
|
8 | // `Data` is typed and exposed below.
|
9 | Parser,
|
10 | Pluggable,
|
11 | PluggableList,
|
12 | Plugin,
|
13 | PluginTuple,
|
14 | Preset,
|
15 | ProcessCallback,
|
16 | Processor,
|
17 | RunCallback,
|
18 | // `Settings` is typed and exposed below.
|
19 | TransformCallback,
|
20 | Transformer
|
21 | } from './lib/index.js'
|
22 |
|
23 | export {unified} from './lib/index.js'
|
24 |
|
25 | // See: <https://github.com/sindresorhus/type-fest/blob/main/source/empty-object.d.ts>
|
26 | declare const emptyObjectSymbol: unique symbol
|
27 |
|
28 | /**
|
29 | * Interface of known results from compilers.
|
30 | *
|
31 | * Normally, compilers result in text ({@linkcode Value} of `vfile`).
|
32 | * When you compile to something else, such as a React node (as in,
|
33 | * `rehype-react`), you can augment this interface to include that type.
|
34 | *
|
35 | * ```ts
|
36 | * import type {ReactNode} from 'somewhere'
|
37 | *
|
38 | * declare module 'unified' {
|
39 | * interface CompileResultMap {
|
40 | * // Register a new result (value is used, key should match it).
|
41 | * ReactNode: ReactNode
|
42 | * }
|
43 | * }
|
44 | *
|
45 | * export {} // You may not need this, but it makes sure the file is a module.
|
46 | * ```
|
47 | *
|
48 | * Use {@linkcode CompileResults} to access the values.
|
49 | */
|
50 | export interface CompileResultMap {
|
51 | // Note: if `Value` from `VFile` is changed, this should too.
|
52 | Uint8Array: Uint8Array
|
53 | string: string
|
54 | }
|
55 |
|
56 | /**
|
57 | * Interface of known data that can be supported by all plugins.
|
58 | *
|
59 | * Typically, options can be given to a specific plugin, but sometimes it makes
|
60 | * sense to have information shared with several plugins.
|
61 | * For example, a list of HTML elements that are self-closing, which is needed
|
62 | * during all phases.
|
63 | *
|
64 | * To type this, do something like:
|
65 | *
|
66 | * ```ts
|
67 | * declare module 'unified' {
|
68 | * interface Data {
|
69 | * htmlVoidElements?: Array<string> | undefined
|
70 | * }
|
71 | * }
|
72 | *
|
73 | * export {} // You may not need this, but it makes sure the file is a module.
|
74 | * ```
|
75 | */
|
76 | export interface Data {
|
77 | settings?: Settings | undefined
|
78 | }
|
79 |
|
80 | /**
|
81 | * Interface of known extra options, that can be supported by parser and
|
82 | * compilers.
|
83 | *
|
84 | * This exists so that users can use packages such as `remark`, which configure
|
85 | * both parsers and compilers (in this case `remark-parse` and
|
86 | * `remark-stringify`), and still provide options for them.
|
87 | *
|
88 | * When you make parsers or compilers, that could be packaged up together,
|
89 | * you should support `this.data('settings')` as input and merge it with
|
90 | * explicitly passed `options`.
|
91 | * Then, to type it, using `remark-stringify` as an example, do something like:
|
92 | *
|
93 | * ```ts
|
94 | * declare module 'unified' {
|
95 | * interface Settings {
|
96 | * bullet: '*' | '+' | '-'
|
97 | * // …
|
98 | * }
|
99 | * }
|
100 | *
|
101 | * export {} // You may not need this, but it makes sure the file is a module.
|
102 | * ```
|
103 | */
|
104 | export interface Settings {
|
105 | [emptyObjectSymbol]?: never
|
106 | }
|