| 1 | {"version":3,"file":"IConfigFile.js","sourceRoot":"","sources":["../../src/documenters/IConfigFile.ts"],"names":[],"mappings":";AAAA,4FAA4F;AAC5F,2DAA2D","sourcesContent":["// Copyright (c) Microsoft Corporation. All rights reserved. Licensed under the MIT license.\n// See LICENSE in the project root for license information.\n\nimport type { IYamlTocFile } from '../yaml/IYamlTocFile';\n\n/**\n * Typescript interface describing the config schema for toc.yml file format.\n */\nexport interface IConfigTableOfContents {\n /**\n * Represents the tree structure describing the toc.file format.\n * Nodes that have an empty `items` array property or their name will be included in the\n * {@link IConfigTableOfContents.nonEmptyCategoryNodeNames} will be filled with API items\n * that are matched with the filters provided. Everything else will be placed under\n * {@link IConfigTableOfContents.catchAllCategory} if provided, which is highly recommended.\n */\n tocConfig: IYamlTocFile;\n\n /**\n * Optional category name that is recommended to be included along with\n * one of the configs: {@link IConfigTableOfContents.categorizeByName} or\n * {@link IConfigTableOfContents.categoryInlineTag}.\n * Any items that are not matched according to the mentioned configuration options will be placed under this\n * catchAll category. If none provided the items will not be included in the final toc.yml file.\n */\n catchAllCategory?: string;\n\n /**\n * Toggle either categorization of the API items should be made based on category name presence\n * in the API item's name. Useful when there are API items without an inline tag to categorize them,\n * but still need to place the items under categories. Note: this type of categorization might place some items\n * under wrong categories if the names are similar but belong to different categories.\n * In case that {@link IConfigTableOfContents.categoryInlineTag} is provided it will try categorize by\n * using it and only if it didn't, it will attempt to categorize by name.\n */\n categorizeByName?: boolean;\n\n /**\n * Inline tag that will be used to categorize the API items. Will take precedence over the\n * {@link IConfigTableOfContents.categorizeByName} flag in trying to place the API item according to the\n * custom inline tag present in documentation of the source code.\n */\n categoryInlineTag?: string;\n\n /**\n * Array of node names that might have already items injected at the time of creating the\n * {@link IConfigTableOfContents.tocConfig} tree structure but are still needed to be included as category\n * nodes where API items will be pushed during the categorization algorithm.\n */\n nonEmptyCategoryNodeNames?: string[];\n}\n\n/**\n * Describes plugin packages to be loaded, and which features to enable.\n */\nexport interface IConfigPlugin {\n /**\n * Specifies the name of an API Documenter plugin package to be loaded. By convention, the NPM package name\n * should have the prefix `doc-plugin-`. Its main entry point should export an object named\n * `apiDocumenterPluginManifest` which implements the {@link IApiDocumenterPluginManifest} interface.\n */\n packageName: string;\n\n /**\n * A list of features to be enabled. The features are defined in {@link IApiDocumenterPluginManifest.features}.\n * The `enabledFeatureNames` strings are matched with {@link IFeatureDefinition.featureName}.\n */\n enabledFeatureNames: string[];\n}\n\n/**\n * This interface represents the api-documenter.json file format.\n */\nexport interface IConfigFile {\n /**\n * Specifies the output target.\n */\n outputTarget: 'docfx' | 'markdown';\n\n /**\n * Specifies what type of newlines API Documenter should use when writing output files.\n *\n * @remarks\n * By default, the output files will be written with Windows-style newlines.\n * To use POSIX-style newlines, specify \"lf\" instead.\n * To use the OS's default newline kind, specify \"os\".\n */\n newlineKind?: 'crlf' | 'lf' | 'os';\n\n /**\n * This enables an experimental feature that will be officially released with the next major version\n * of API Documenter. It requires DocFX 2.46 or newer. It enables documentation for namespaces and\n * adds them to the table of contents. This will also affect file layout as namespaced items will be nested\n * under a directory for the namespace instead of just within the package.\n *\n * This setting currently only affects the 'docfx' output target. It is equivalent to the `--new-docfx-namespaces`\n * command-line parameter.\n */\n newDocfxNamespaces?: boolean;\n\n /** {@inheritDoc IConfigPlugin} */\n plugins?: IConfigPlugin[];\n\n /** {@inheritDoc IConfigTableOfContents} */\n tableOfContents?: IConfigTableOfContents;\n\n /**\n * Specifies whether inherited members should also be shown on an API item's page.\n */\n showInheritedMembers?: boolean;\n}\n"]} |