📣 Build dart types from Swagger/OpenAPI schemas 📣

SwaggerDartCodeGenerator is a code generator that looks for *.swagger files and builds .swagger.dart files, based on the schema. Code generation based on Chopper and JsonAnnotation models and can be configured for your needs.

---

Overview

In general case for each .swagger file three outputs will be created.
.dart generated by Swagger dart code generator, contains all models, requests, converters, etc.
[Since v1.2.0] .enums.dart generated by Swagger dart code generator, contains all enums and enums mappings.
.chopper.dart - generated by chopper.
.g.dart - generated by json_serializable.

Installation

The generated code uses the following packages in run-time:

dependencies:
  chopper: ^6.1.1
  json_annotation: ^4.8.0

Add the following to your pubspec.yaml file to be able to do code generation:

dev_dependencies:
  build_runner: ^2.3.3
  chopper_generator: ^6.0.0
  json_serializable: ^6.6.1
  swagger_dart_code_generator: ^2.10.4

Then run:

pub packages get

or

flutter packages get

Now SwaggerGenerator will generate the API files for you by running:

pub run build_runner build

or

flutter pub run build_runner build

Configuration

Swagger generator offers some configuration options to generate code. All options should be included on build.yaml file on the root of the project:

targets:
  $default:
    builders:
      swagger_dart_code_generator:
        options:
          # custom configuration options!

Option	Default value	Is required	Description
input_folder	-	true	Path to folder with .swagger files (for ex. swagger_examples, or lib/swaggers).
output_folder	-	true	Path to output folder (for ex. lib/generated).
input_urls	[]	false	Here you can mention list of files to be downloaded from the internet. You can check example of usage.
with_base_url	true	false	If this option is false, generator will ignore base url in swagger file.
use_required_attribute_for_headers	true	false	If this option is false, generator will not add @required attribute to headers.
with_converter	true	false	If option is true, combination of all mappings will be generated.
ignore_headers	false	false	If option is true, headers will not be generated.
additional_headers	false	false	List of additional headers, not specified in Swagger. Example of usage: build.yaml
enums_case_sensitive	true	false	If value is false, 'enumValue' will be defined like Enum.enumValue even it's json key equals 'ENUMVALUE'
include_paths	[]	false	List of Regex If not empty - includes only paths matching reges
exclude_paths	[]	false	List of Regex If not empty -exclude paths matching reges
classes_with_nullabe_lists	[]	false	List of regex strings. If class name matches any of regex - list properties will have default value null. Otherwise it will be empty list. If you used use_default_null_for_lists: true, just set .* value for this property and result will be same. Check example for more details
build_only_models	false	false	If option is true, chopper classes will not be generated.
separate_models	false	false	If option true, generates models into separate file.
include_if_null	null	false	Sets includeIfNull JsonAnnotation feature and sets value for it. If null - not set anything.
default_values_map	[]	false	Contains map of types and theirs default values. See DefaultValueMap.
response_override_value_map	[]	false	Contains map of responses and theirs overridden values. See ResponseOverrideValueMap.
cut_from_model_names	-	false	If your model names are long and contain a lot of duplicated words, for example DbUsersModelsV3GeneralUserModel, you can cut off duplicated part, using cut_from_model_names : DbUsersModelsV3. Also, you can use regex expressions in this parameter.
nullable_models	-	false	List of model names should have force-nullable properties. Example of usage in build.yaml.
override_equals_and_hashcode	-	true	If need to decrease app size - you can disable generation of hashcode and Equals method.
overriden_models	-	false	List of manually written models that will replace the generated one. These models will not be generated.
use_path_for_request_names	true	false	Can be false only if all requests has unique operationId. It gives readable names for requests.

It's important to remember that, by default, build will follow Dart's package layout conventions, meaning that only some folders will be considered to parse the input files. So, if you want to reference files from a folder other than lib/, make sure you've included it on sources:

targets:
  $default:
    sources:
      - lib/**
      - swagger_examples/**
      - swaggers/**

Default Value Map for model generation

If you want to add defaultValue: attribute to fields with concrete type you can use default value map. Please see next example:

targets:
  $default:
    builders:
      swagger_dart_code_generator:
        options:
          input_folder: 'lib/swaggers'
          output_folder: 'lib/generated_code/'
          default_values_map:
            - type_name: int
              default_value: '36'
            - type_name: String
              default_value: 'default'
            - type_name: 'List<String>'
              default_value: '[]'
          exclude_paths:
            - '\/cars\/get'
          include_paths:
            - '\/popular\/cars'

Response Override Value Map for requests generation

If you want to override response for concrete request, you can use response_override_value_map. For example:

targets:
  $default:
    builders:
      swagger_dart_code_generator:
        options:
          input_folder: 'lib/swaggers'
          output_folder: 'lib/generated_code/'
          response_override_value_map:
            - url: '/store/inventory'
              method: get
              overridden_value: 'List<dynamic>'
            - url: '/news/latest'
              method: put
              overridden_value: 'MyPerfectType'

Check the examples to see how to use it in details.