Skip to content

SOAR-0015: Add namespace file splitting proposal - #930

Open
nac5504 wants to merge 2 commits into
apple:mainfrom
nac5504:soar-0015
Open

SOAR-0015: Add namespace file splitting proposal#930
nac5504 wants to merge 2 commits into
apple:mainfrom
nac5504:soar-0015

Conversation

@nac5504

@nac5504 nac5504 commented Aug 3, 2026

Copy link
Copy Markdown

Summary

Notes

The proposal is scoped to the initial namespace split from PR #925: Types.swift, Types+Components.swift, and Types+Operations.swift. More advanced sharding remains listed only as future direction.

Validation

  • git diff --check

@nac5504 nac5504 changed the title Add namespace file splitting proposal SOAR-0015: Add namespace file splitting proposal Aug 3, 2026
@nac5504
nac5504 marked this pull request as ready for review August 3, 2026 16:40

- `output.types.fileSplitting.strategy`, currently supporting `namespace`.

The same model is used by YAML configuration, direct command-line invocation, and programmatic callers that construct `_OpenAPIGeneratorCore.Config` directly.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remove these implementation details. The design details should be about the conceptual approach and user-visible concepts.

There are many possible implementations, so no need to lock that in the proposal, in fact it can distract from where users should provide feedback - on the API and config file, not on the implementation.


#### Build-tool plugin boundary

SwiftPM and Xcode build-tool plugins must declare generated output files before invoking the generator executable. PR #925 therefore rejects build-tool plugin invocations when `output.types.fileSplitting` is configured.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm this is unfortunate - we should discuss more what our options are.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not being able to support this in the build plugin might actually be an argument for switching this to be the default and making this not even configurable. What do folks think?


- `Types.swift` for root declarations.
- `Types+Components.swift` for the generated `Components` namespace.
- `Types+Operations.swift` for the generated `Operations` namespace.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should go one level deeper - one file for #/components/schemas, one file for #/components/parameters, etc.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is exactly the follow-up PR I am drafting. It provides a config option to specify if you want the first-level namespaces split or the second-level.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should discuss this more - whether and how much can actually be configurable, considering the limitation on build plugins.

#930 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants