Tags: apple/swift-openapi-generator
Add support for configurable comments in generated files (#773) ### Motivation Users want the ability to add custom comments to generated files. One concrete use case is adding directives like `swift-format-ignore-file` and `swiftlint:disable all` to prevent these tools from processing generated code. ### Modifications - Added `additionalFileComments` property to `Config` and `UserConfig` structs - Modified `FileTranslator` to include additional comments along with the do-not-edit comment - Added CLI support with `--additional-file-comment` option - Added config tests to confirm the option propagates and the default is empty - Added snippet tests to validate the actual rendering - Updated documentation with examples and usage instructions ### Result Users can now configure additional comments to be added to generated files using either the config file or a command line option. Fixes #738. ### Test plan - Added unit tests for `Config` - Added snippet tests for rendering - Manual tests of generator using config and CLI on real OpenAPI doc: ```console % swift run swift-openapi-generator generate openapi-documents/petstore.yaml \ --mode types \ --output-directory test-output-cli \ --additional-file-comment "hello world" \ --additional-file-comment "testing, testing, 1, 2, 3" Build of product 'swift-openapi-generator' complete! (3.27s) Swift OpenAPI Generator is running with the following configuration: - OpenAPI document path: /Users/Si/work/code/swift-openapi-workspace/packages/swift-openapi-generator/openapi-documents/petstore.yaml - Configuration path: <none> - Generator modes: types - Access modifier: internal - Naming strategy: defensive - Name overrides: <none> - Feature flags: <none> - Output file names: Types.swift - Output directory: /Users/Si/work/code/swift-openapi-workspace/packages/swift-openapi-generator/test-output-cli - Diagnostics output path: <none - logs to stderr> - Current directory: /Users/Si/work/code/swift-openapi-workspace/packages/swift-openapi-generator - Plugin source: <none> - Is dry run: false - Additional imports: <none> - Additional file comments: hello world, testing, testing, 1, 2, 3 Writing data to file Types.swift... % head -5 test-output-cli/Types.swift // Generated by swift-openapi-generator, do not modify. // hello world // testing, testing, 1, 2, 3 @_spi(Generated) import OpenAPIRuntime ```
[Cleanup] Make Config's namingStrategy and accessModifier params cons… …istent (#713) ### Motivation A missed fixup from #708: #708 (comment) ### Modifications Removed the default from Config.init and forced all callers to make a choice on the naming strategy, just like for accessModifier. ### Result Consistent handling of these two parameters. ### Test Plan Tests passed locally.
Idiomatic naming strategy as opt-in (#679) ### Motivation Implementation of #683. ### Modifications - Implemented the SOAR-0013 idiomatic naming strategy - Added name overrides - Switched most reference tests to use the new strategy - Updated some docs (I'll update the rest after this lands and gets released, then I can update Examples and IntegrationTest) ### Result SOAR-0013 implemented. ### Test Plan Updated and added new unit tests. --------- Co-authored-by: Si Beaumont <[email protected]> Co-authored-by: Si Beaumont <[email protected]>
Access properties with explicit self in `encode(to encoder:)` (#699) ### Motivation In #696 we avoided clashing with a property called `container` in certain schemas by making use of explicit self in `init(from decoder:)`. We didn't have access to the OpenAPI document and hadn't caught the case where this was used in a schema that supported additional properties, where we also need to avoid the clash in `encode(to encoder:)`. ### Modifications - Access properties with explicit self in `encode(to encoder:)`. ### Result - Fixes #695 ### Test Plan More snippet tests and reference tests.
Add a note about an open issue with code generation and SourceKit-LSP (… …#642) Following the discussion on Slack, this adds a note for users of SourceKit-LSP informing them that the default code generation might not work as expected and offers a possible workaround. https://swift-open-source.slack.com/archives/C02PV8T5HQD/p1726815970093299 Only updates documentation. Let me know if you feel this is the right place for this information?
Avoid repeating dependency names in code (#630) ### Motivation A small refactor - avoid repeating the dependency names in code. ### Modifications Factor out the dependency names into a single place. ### Result Less duplication that needs to be kept in sync manually. ### Test Plan All tests still pass.
PreviousNext