The Swagger builder provides an option to specify a list of split Swagger specs in order to generate (and apply the merging strategy) several Swagger specs in one command.
The list of specifications is described in a json file provided to the tool via the --apis options. The file has to follow a provided Json Schema.
The API-listing file will contain only the field apis which is an array of objects containing the following fields:
| Field | Description | Default value |
|---|---|---|
| outputFormat | Type of artifact generated. The supported formats are split and yaml |
yaml |
| output | Path of the artifact generated. In case of yaml output format, the .yaml extension will be added to the path.In the case of split output format, the output path will be the name of the folder containing the generated split spec. |
*required |
| setVersion | Set the version of the final Swagger spec. If not specified, the most recent version of the specification (in input) will be used | null |
| setVersionAuto | If enabled, the version from the current package.json will be applied to the final swagger specification. This option will be ignored if a manual version is specified in setVersion configuration. | null |
| artifact | Name of the NPM artifact associated to the Swagger specification generated. If specified, a package.json will be generated alongside the Swagger specification (in the same folder) |
null |
| ignoreConflict | Ignore the conflict (in the paths) during the specification merge. If enabled, the previous conflicting path will be replaced by the new one (in the Merging strategy) | false |
| awsCompat | Enable the Amazon Web Service Gateway compatibility. The resulting Swagger specification will be transformed to be compatible with AWS | false |
| treeShaking | Enable the tree shaking of the Swagger output. The definitions and parameters not referred by a path will be removed. This option is enabled by default in case of black/white listing |
false |
| treeShakingStrategy | Change the tree shaking strategy. Options are bottom-up or top-down. |
bottom-up |
| validation | Enable the validation of the generated Swagger specification | true |
| pathsWhiteList | List of whitelisted paths to keep to the final Swagger specification. If specified, the tree shaking post process will be run to the Swagger specification |
null |
| pathsBlackList | List of blacklisted paths to remove from the final Swagger specification. If specified, the tree shaking post process will be run to the Swagger specification |
null |
| swaggerTemplate | Path (or list of paths) to a yaml file that contains the envelope of your API (info, schemes...).The path(s) must be relative to the configuration file. Everything that is not tags, parameters, paths, definitions or securityDefinition can be defined in this file.In case of list of files, the files will be merged according to the array order. Instead of a path(s), an object containing the template can be provided |
*required |
| products | List of API products to include in the specification, corresponding to a yaml file in the ./products folder (relative to the json file position) or in one of the folders listed in productFolders configuration.example: the product Core Ex will include the file ./products/Core Ex.yaml |
*required |
| productFolders | List of folders containing products (relative to the json file position) |
null |
| flattenConflictedDefinition | Merge based interface with new override in case of definition name conflict | false |
[!NOTE] This is actually the merge of the
configurationand thesplit consolidation.