1 | import type { IYamlTocFile } from '../yaml/IYamlTocFile';
|
2 | /**
|
3 | * Typescript interface describing the config schema for toc.yml file format.
|
4 | */
|
5 | export interface IConfigTableOfContents {
|
6 | /**
|
7 | * Represents the tree structure describing the toc.file format.
|
8 | * Nodes that have an empty `items` array property or their name will be included in the
|
9 | * {@link IConfigTableOfContents.nonEmptyCategoryNodeNames} will be filled with API items
|
10 | * that are matched with the filters provided. Everything else will be placed under
|
11 | * {@link IConfigTableOfContents.catchAllCategory} if provided, which is highly recommended.
|
12 | */
|
13 | tocConfig: IYamlTocFile;
|
14 | /**
|
15 | * Optional category name that is recommended to be included along with
|
16 | * one of the configs: {@link IConfigTableOfContents.categorizeByName} or
|
17 | * {@link IConfigTableOfContents.categoryInlineTag}.
|
18 | * Any items that are not matched according to the mentioned configuration options will be placed under this
|
19 | * catchAll category. If none provided the items will not be included in the final toc.yml file.
|
20 | */
|
21 | catchAllCategory?: string;
|
22 | /**
|
23 | * Toggle either categorization of the API items should be made based on category name presence
|
24 | * in the API item's name. Useful when there are API items without an inline tag to categorize them,
|
25 | * but still need to place the items under categories. Note: this type of categorization might place some items
|
26 | * under wrong categories if the names are similar but belong to different categories.
|
27 | * In case that {@link IConfigTableOfContents.categoryInlineTag} is provided it will try categorize by
|
28 | * using it and only if it didn't, it will attempt to categorize by name.
|
29 | */
|
30 | categorizeByName?: boolean;
|
31 | /**
|
32 | * Inline tag that will be used to categorize the API items. Will take precedence over the
|
33 | * {@link IConfigTableOfContents.categorizeByName} flag in trying to place the API item according to the
|
34 | * custom inline tag present in documentation of the source code.
|
35 | */
|
36 | categoryInlineTag?: string;
|
37 | /**
|
38 | * Array of node names that might have already items injected at the time of creating the
|
39 | * {@link IConfigTableOfContents.tocConfig} tree structure but are still needed to be included as category
|
40 | * nodes where API items will be pushed during the categorization algorithm.
|
41 | */
|
42 | nonEmptyCategoryNodeNames?: string[];
|
43 | }
|
44 | /**
|
45 | * Describes plugin packages to be loaded, and which features to enable.
|
46 | */
|
47 | export interface IConfigPlugin {
|
48 | /**
|
49 | * Specifies the name of an API Documenter plugin package to be loaded. By convention, the NPM package name
|
50 | * should have the prefix `doc-plugin-`. Its main entry point should export an object named
|
51 | * `apiDocumenterPluginManifest` which implements the {@link IApiDocumenterPluginManifest} interface.
|
52 | */
|
53 | packageName: string;
|
54 | /**
|
55 | * A list of features to be enabled. The features are defined in {@link IApiDocumenterPluginManifest.features}.
|
56 | * The `enabledFeatureNames` strings are matched with {@link IFeatureDefinition.featureName}.
|
57 | */
|
58 | enabledFeatureNames: string[];
|
59 | }
|
60 | /**
|
61 | * This interface represents the api-documenter.json file format.
|
62 | */
|
63 | export interface IConfigFile {
|
64 | /**
|
65 | * Specifies the output target.
|
66 | */
|
67 | outputTarget: 'docfx' | 'markdown';
|
68 | /**
|
69 | * Specifies what type of newlines API Documenter should use when writing output files.
|
70 | *
|
71 | * @remarks
|
72 | * By default, the output files will be written with Windows-style newlines.
|
73 | * To use POSIX-style newlines, specify "lf" instead.
|
74 | * To use the OS's default newline kind, specify "os".
|
75 | */
|
76 | newlineKind?: 'crlf' | 'lf' | 'os';
|
77 | /**
|
78 | * This enables an experimental feature that will be officially released with the next major version
|
79 | * of API Documenter. It requires DocFX 2.46 or newer. It enables documentation for namespaces and
|
80 | * adds them to the table of contents. This will also affect file layout as namespaced items will be nested
|
81 | * under a directory for the namespace instead of just within the package.
|
82 | *
|
83 | * This setting currently only affects the 'docfx' output target. It is equivalent to the `--new-docfx-namespaces`
|
84 | * command-line parameter.
|
85 | */
|
86 | newDocfxNamespaces?: boolean;
|
87 | /** {@inheritDoc IConfigPlugin} */
|
88 | plugins?: IConfigPlugin[];
|
89 | /** {@inheritDoc IConfigTableOfContents} */
|
90 | tableOfContents?: IConfigTableOfContents;
|
91 | /**
|
92 | * Specifies whether inherited members should also be shown on an API item's page.
|
93 | */
|
94 | showInheritedMembers?: boolean;
|
95 | }
|
96 | //# sourceMappingURL=IConfigFile.d.ts.map |
\ | No newline at end of file |