-
Notifications
You must be signed in to change notification settings - Fork 125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use the same .swift-format in the repo and in the generated code #40
Comments
I've opened a PR for this. Please have a look. |
Well, this is good timing: swiftlang/swift-package-manager#6067 Unfortunately, it's only supported in Swift 5.9, so I propose we punt this issue until later, and adopt it when we bump the minimum tools version to 5.9. |
Sounds good to me. So sometime in the fall when Xcode 15 comes out of beta I assume? |
To be determined, but marking as blocked for now. You can close your other PR for now, but we'll definitely appreciate the contribution when Swift OpenAPI Generator requires Swift tools version 5.9! |
Filed #75 to properly relate the two. |
[Generator] Integrate the new URI and String coders ### Motivation Depends on runtime changes from apple/swift-openapi-runtime#45. Up until now, we relied on a series of marker and helper protocols `_StringConvertible` and `_AutoLosslessStringConvertible` to handle converting between various types and their string representation. This has been very manual and required a non-trivial amount of work to support any extra type, especially `Date` and generated string enums. Well, turns out this was an unnecessarily difficult way to approach the problem - we had a better solution available for a long time - `Codable`. Since all the generated types and all the built-in types we reference are already `Codable`, there is no need to reinvent a way to serialize and deserialize types, and we should just embrace it. While a JSON encoder and decoder already exists in Foundation, we didn't have one handy for encoding to and from URIs (used by headers, query and path parameters), and raw string representation (using `LosslessStringConvertible`). We created those in the runtime library in PRs apple/swift-openapi-runtime#44 and apple/swift-openapi-runtime#41, and integrated them into our helper functions (which got significantly simplified this way) in apple/swift-openapi-runtime#45. Out of scope of this PR, but this also opens the door to supporting URL form encoded bodies (#182), multipart (#36), and base64 (#11). While this should be mostly invisible to our adopters, this refactoring creates space for implementing more complex features and overall simplifies our serialization story. ### Modifications - Updated the generator to use the new helper functions. - Updated the article about serialization, shows how we reduced the number of helper functions by moving to `Codable`. - Set the `lineLength` to 120 on the formatter configuration, it was inconsistent with our `.swift-format` file, and lead to the soundness script trying to update the reference files, but then the reference tests were failing. Since we're planning to sync these in #40, this is a step closer to it, but it means that it's probably best to review this PR's diff with whitespace ignored. ### Result Now the generated code uses the new helper functions, allowing us to delete all the deprecated helpers in 0.2.0. ### Test Plan Updated file-based reference, snippet, and unit tests. Reviewed by: glbrntt Builds: ✔︎ pull request validation (5.8) - Build finished. ✔︎ pull request validation (5.9) - Build finished. ✔︎ pull request validation (docc test) - Build finished. ✔︎ pull request validation (integration test) - Build finished. ✔︎ pull request validation (nightly) - Build finished. ✔︎ pull request validation (soundness) - Build finished. #226
@czechboy0 if #75 is 1.0, can't this be under the same milestone as well? |
We don't use swift-format as a library anymore, so this is obsolete. |
We use swift-format both for formatting the generator code, and the generated code. However, the configuration is duplicated in both places, we should have one source of truth for it instead.
The text was updated successfully, but these errors were encountered: