Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
New generator swift5 #4086
Description of the PR
This PR adds basic support for Swift 5 and it lowers the barrier of any Swift 5 contribution.
This PR fixes #2721
@4brunu I'm trying to remove all dependencies including Alamofire since this client shouldn't have any dependencies. We want to select own API Clients and response type, including Combine, by myself.
Instead, in other repository, we should provide example API Client for users so we can focus on implementing OAS itself.
We Swift developers hope to make this generator stable for reducing developing time.
I see what you mean. I can only share my experience working on this project. You will always find users who want to use a particular HTTP library: Java client now supports 10+ HTTP libraries: feign, okhttp, Dart supports 2 or 3 via different generators. TS supports a lot via different generators.
Besides Alamofire, there's another one by IBM: https://github.com/IBM-Swift/SwiftyRequest
I'm not surprised if we are going to see a request from the user to support SwiftyRequest in the not too distant future.
My take is to support a swappable ApiClient class from day one and leave it up to the user to choose which HTTP library they want to use.
(and it's perfectly fine we disagree on different things)
@d-date I also prefer to reduce the number of dependencies, so it would be nice to rely on
But on the other hand I think it would be nice to provide an optional integration with `RxSwift.
My concern with a big new Swift 5 generator is how long it will take, because we could introduce so many improvements,
This PR actually doesn't provide any value in itself, because it's the same as in Swift 4, but it will lower the barrier to anyone that wants to contribute with improvements to the Swift 5 generator.
What do you think of a more incremental approach?
By the way, I'm totally ok closing this PR
I would merge this as is. My current use case is: I am using Swagger 2 until now, with Swift 5, and want to update to Swagger 3. So I just want to update the Swagger version while keeping the rest as it is.
I understand that there is room for improvement (decoupling from networking dependencies, adding other networking options) but I too believe this should be delivered incrementally.
* master: (275 commits) Initial CODEOWNERS (OpenAPITools#4924) [scala] Support for Set when array has uniqueItems=true (OpenAPITools#4926) remove nodejs server samples, scripts (OpenAPITools#4919) Added ability to work with `defaultHeaders` and fixed authentication for code generated by openapi-generator for typescript-node (OpenAPITools#4896) replace petstore_api with packageName (OpenAPITools#4921) remove base_object_spec.mustache from ruby client (OpenAPITools#4918) Add an link to Ada article (OpenAPITools#4920) avoid using hardcode prefix in example (OpenAPITools#4917) [dart-dio] Fix basepath (OpenAPITools#4911) [java][client] jackson update (OpenAPITools#4907) [Swift] Minor improvements to swift 5 generator (OpenAPITools#4910) [cpp-restbed] Added "out-of-the-box" functionality (OpenAPITools#4759) New generator swift5 (OpenAPITools#4086) [dart-dio] Adds support for multipart form data post body (OpenAPITools#4797) [go][client] fix when schema have multiple servers (OpenAPITools#4901) Unables CI tests of python-flask-python2 (OpenAPITools#4889) [C-libcurl] The JSON key name in request/response body should not be escaped even though it is a C key word. (OpenAPITools#4893) upgrade to JUnit 4.13 (OpenAPITools#4899) [r] Ignoring README.md in Rbuildignore (OpenAPITools#4898) update samples ...