@swipesight (2018/09) @jaumard (2018/09) @josh-burton (2019/12) @amondnet (2019/12) @sbu-WBT (2020/12) @kuhnroyal (2020/12) @agilob (2020/12)

You should test if the minimum supported Dart version needs to be raised.

json_serializer now has version 4.0.0 which will require updating dart version, but so far this is ok. I don't want to make too many changes at once here. eg. default value isn't support yet here, nor standalone enums, but it's a major move forward I think. It will open way for @k-paxian to add dart-json-mapper serializer in client library.

I am sure not the current approach with the part files will work. Have you run the build runner? I think you are missing the model part files and since only one part (of) is allowed, this might fail.

Maybe we first need to get rid of the current part files and use correct exports.

I am sure not the current approach with the part files will work. Have you run the build runner? I think you are missing the model part files and since only one part (of) is allowed, this might fail.

Neither I am, but this actually works quite nice. Instead producing really verbose files, one .g.dart for each model it generates one big api.g.dart which has serialization code for all models. It's much nicer to see in IDE. The project builds:

❯ pwd
/home/agilob/Projects/openapi-generator/samples/openapi3/client/petstore/dart2/petstore_json_serializable_client_lib_fake
 pub get && pub run build_runner build
Resolving dependencies... 
Got dependencies!
Precompiling executable... (8.6s)
Precompiled build_runner:build_runner.
[INFO] Generating build script completed, took 242ms
[INFO] Reading cached asset graph completed, took 44ms
[INFO] Checking for updates since last build completed, took 324ms
[INFO] Running build completed, took 19ms
[INFO] Caching finalized dependency graph completed, took 25ms
[INFO] Succeeded after 51ms with 0 outputs (0 actions)

And maybe get rid of the new empty lines to reduce noise.

Check commit history... and I give up, the new empty lines are result of

{{/json_serializable}}
{{#json_serializable}}

I'd rather have nicer mustache template than autogenerated code that shouldn't me modified manually anyway... (and we recommend running dartfmt after generation). You can remove whitespaces from GH review in options.

Travis failing

anyrequests: You have reached your pull rate limit.
You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit

@wing328

That is good but I know a lot of generators where this will not work. So we should do that anyway, but then it can be independent of this change.

There seems to be some transformer stuff left in the api client and helper that doesnt compile.

That is good but I know a lot of generators where this will not work. So we should do that anyway, but then it can be independent of this change.

I propose to do it after this change, I find this PR to be too much in one go already.

There seems to be some transformer stuff left in the api client and helper that doesnt compile.

Unfortunately this is where we're hitting temporary limitation of json_serializable and for now I can't add this module to pom.xml

it doesn't generate mapping for enums that are not used in classes. This is purely temporary as this api-helper and api-client are redundant for this functionality. Each class has its own toJson and fromJson method now, but I'm going to keep it in this PR for backwards consistency. Both native and j_s serializes now can be used interchangeably.

I see, so you want this merged to have the basic infrastructure in place although the json_serializable option does not completely work yet. I agree in that regard, maybe we should log some warning when this option is set until it is completely working.

That is good but I know a lot of generators where this will not work. So we should do that anyway, but then it can be independent of this change.

I propose to do it after this change, I find this PR to be too much in one go already.

I agree, this is out of scope.

I agree in that regard, maybe we should log some warning when this option is set until it is completely working.

I'll add default value support after this gets in. It doesn't have to be perfect on the first merge. defaultValue flag is also incompatible with nullable flag in json_serializable so this need to be conditional support in mustache template, which I simply avoided doing now. This is big already. I'll add this later, but also very soon.

If you think this looks good, can we get this merged please @kuhnroyal and @wing328 ?

I think changing the enum templates to }{{/json_serializable}}{{#json_serializable}} removes the new lines if you want. Otherwise I am good with this.

Done!

@agilob thanks for the PR. Please resolve the merge conflicts when you've time.

@wing328 done

@wing328 can we get this in please? I want to add a few more features to this generator while I still have time for it

Just merged. Thanks again for the PR.