OpenAPI/Swagger 3.0 Parser and Swift code generator
SwagGen is a library and command line tool for parsing and generating code for OpenAPI/Swagger 3.0 specs, completely written in Swift.
Swagger 2 support has been removed. For Swagger 2 use version
3.0.2
or theswagger_2
branch
It contains a Swagger
library that can be used in Swift to load and parse Swagger specs.
SwagGen
is command line tool that generates code from a OpenAPI/Swagger 3.0 spec.
Templates for any language can be written that leverage this generator.
SwagGen
includes a bundled template for generating a client side Swift library for interfacing with the Swagger spec. It includes support for model inheritance, shared enums, discrete and mutable request objects, inline schemas, Codable and Equatable models, configurable options, generic networking stack, and many other niceties.
Make sure Xcode 11+ is installed first.
$ mint install yonaskolb/SwagGen
$ brew tap yonaskolb/SwagGen https://github.com/yonaskolb/SwagGen.git
$ brew install SwagGen
$ git clone https://github.com/yonaskolb/SwagGen.git
$ cd SwagGen
$ make install
$ git clone https://github.com/yonaskolb/SwagGen.git
$ cd swaggen
$ swift run
Add the following to your Package.swift file’s dependencies:
.package(url: "https://github.com/yonaskolb/SwagGen.git", from: "4.4.0"),
And then import wherever needed:
import SwagGenKit
import Swagger
Use --help
to see usage information
swaggen --help
Usage: swaggen <command> [options]
Commands:
generate Generates a template from a Swagger spec
help Prints this help information
version Prints the current version of this app
swaggen generate path_to_spec
Use swaggen generate --help
to see the list of generation options.
spec: This is the path to the Swagger spec and is a required parameter. It can either be a file path or a web url to a YAML or JSON file
–language: The language to generate a template for. This defaults to swift
for now.
–template:: This is the path to the template config yaml file. It can either be a direct path to the file, or a path to the parent directory which will by default look for /template.yml
. If this is not passed, the default template for the language will be used.
–destination: The directory that the generated files will be added to.
–option: An option that will be merged with the template config options with those in this argument taking precedence, meaning any existing options of the same name will be overwritten. This argument can be repeated to pass in multiple options. Options must specify the option name and option value separated by a colon, with any spaces contained in quotes. Nested options in dictionaries can be set by using a dot syntax. The following formats are allowed:
-- option myOption:myValue
-- option modelSuffix: Model
-- option propertyNames.identifier: id
-- option "myOption: my value"
–clean: Controls if and how the destination directory is cleaned of non generated files. Options are:
none
: no files are removed (default)all
: all other files are removedleave.files
: all files and directories except those that start with .
in the destination directory are removed. This is useful for keeping configuration files and directories such as .git
around, while still making sure that items removed from the spec are removed from the generated API.–verbose: Show more verbose output
–silent: Silences any standard output. Errors will still be shown
Example:
swaggen generate http://myapi.com/spec --template Templates/Swift --destination generated --option name:MyAPI --option "customProperty: custom value --clean leave.files"
For the Swift template, a handy option is name
, which changes the name of the generated framework from the default of API
. This can be set in the template or by passing in --option name:MyCoolAPI
.
List of all available options:
name | action | expected values | default value |
---|---|---|---|
name | name of the API | String |
API |
authors | authors in podspec | String |
Yonas Kolb |
baseURL | baseURL in APIClient | String |
first scheme, host, and base path of spec |
fixedWidthIntegers | whether to use types like Int32 and Int64 | Bool |
false |
homepage | homepage in podspec | String |
https://github.com/yonaskolb/SwagGen |
modelPrefix | model by adding a prefix and model file name | String |
null |
modelSuffix | model by adding a suffix and model file name | String |
null |
mutableModels | whether model properties are mutable | Bool |
true |
modelType | whether each model is a struct or class |
String |
class |
modelInheritance | whether models use inheritance. Must be false for structs | Bool | true |
modelNames | override model names | [String: String] |
[:] |
modelProtocol | customize protocol name that all models conform to | String |
APIModel |
enumNames | override enum names | [String: String] |
[:] |
enumUndecodableCase | whether to add undecodable case to enums | Bool |
false |
propertyNames | override property names | [String: String] |
[:] |
safeArrayDecoding | filter out invalid items in array instead of throwing | Bool |
false |
safeOptionalDecoding | set invalid optionals to nil instead of throwing | Bool |
false |
tagPrefix | prefix for all tags | String |
null |
tagSuffix | suffix for all tags | String |
null |
codableResponses | constrains all responses to be Codable |
Bool |
false |
anyType | override Any with custom type |
String |
Any |
numberType | override default number type when format not specified | String |
Double |
If writing your own Swift template there are a few types that are generated that you will need to provide typealias’s for:
ID
: The UUID
format. Usually UUID
or String
File
: The file
format. Usually URL
, Data
or a custom type with a mimeType and fileNameDateTime
: The date-time
format. Usually Date
DateDay
: The date
format. Usually Date
or a custom type.If you want to pass any required arguments when running in Xcode, you can edit the scheme to include launch arguments.
Templates are made up of a template config file, a bunch of Stencil files, and other files that will be copied over during generation
This is the configuration and manifest file for the template in YAML or JSON format. It can contain:
Swift
definitions
gets it’s own definition context). Note that properties in the template options
field can be used heredefinitions
then the path could be Models/{{ type }}.swift
and the filename would be the type of the definition. If this is left out the destination will be the same as the path, relative to the final destination directory. If it resolves to an empty string it will be skipped and not generated.options
argument, with the argument options taking precendance. These options can be references in template file paths and their contents.An example template for Swift can be found here
These files follow the Stencil file format outlined here https://stencil.fuller.li
Formatters change what information is available to the templates and how it’s formatted. They can be specified via the formatter
property in the template config. Usually these would map to a specific target language, but can be customized for different purposes.
SwagGen can be used to generate code for any language. At the moment there is only a formatter and template for Swift
Usage documentation can be found in the Readme that is generated with your template.
This tool is powered by:
Thanks also to Logan Shire and his initial work on Swagger Parser
Pull requests and issues are welcome
SwagGen is licensed under the MIT license. See LICENSE for more info.