Skip to content

Conversation

d-ronnqvist
Copy link
Contributor

@d-ronnqvist d-ronnqvist commented Sep 23, 2025

Bug/issue #, if applicable:

Summary

The term "bundle" in DocC is a bit overloaded and can be confusing to newcomers.

On the user-facing side, "bundle" could refer to either the inputs (the documentation catalog) or the outputs (the documentation archive). We're quite good with that terminology in user-facing documentation and user-facing communication in the Swift Forums. However, for contributors there's still plenty of places in DocC that refer to a catalog as a bundle (and, I found, even some that refer to an archive as a bundle). There's also a fair amount of API that use the term "bundle" that sometimes refers to the catalog and sometimes refers to something else.

This PR aims to align the terminology used in contributor documentation and API with the user-facing terminology.

About 1/3 of the charges are in "Sources" and 2/3 in "Tests":

Sources   104 files changed,  836 insertions(+),  813 deletions(-)
Tests     130 files changed, 2169 insertions(+), 2358 deletions(-)

The main bit of updated API is DocumentationBundle which was previously aliased to DocumentationContext.Inputs and documented to be "A collection of the build inputs for a unit of documentation". This PR switches that around so that DocumentationContext.Inputs is the primary name and DocumentationBundle is the deprecated, to be removed, name.

This better aligns with what this type represents (and with its documentation). There are two reasons why this isn't really the same as the catalog:

  • It's possible to have "inputs" without a catalog or additional "inputs" besides a catalog
  • When the input comes from a catalog, the Inputs type represents a mild processing of the catalog's content; categorizing files by kind and parsing its metadata.

The second major change in this PR has to do with types that hold both a context and its inputs. See for example: DocumentationContextConverter, DocumentationNodeConverter, ConvertActionConverter, AutomaticCuration, RenderContentCompiler, DocumentationContentRenderer, RenderHierarchyTranslator, RenderNodeTranslator, RenderContext, MarkupReferenceResolver, ReferenceResolver, etc.

With #1059 deprecating the two-stage context creation and #1266 removing it, a documentation context is now guaranteed to have exactly one input. This means that API that used to have both a context parameter and an inputs/bundle parameter no longer needs the second parameter because the information can be accessed as a property of the context. In fact, removing the second parameter designs away the possibility of passing a collection of inputs that the context doesn't know of. See 962d0e4.

Further, now that the inputs could be accessed from the context, the various test helpers that return both a context and its inputs only need to return the context. Most of the time this was all that the caller needed and when the caller needed both, the inputs was a simple property access away.


While I was already modifying 2k LOC of tests, I took the opportunity to rename these test helpers. They used to be called testBundleAndContext which needed an update anyway, because they no longer returned the "bundle".

I opted to name these API 3 different things:

  • makeEmptyContext() for the test helper that creates a completely empty context
  • loadFromDisk(...) for the test helpers that perform real file system I/O
  • load(catalog:...) for the test helper that uses a virtual file system

I feel that these new names clarifies what's happening at the call site; when the context is empty and when there's real file system I/O involved.

While updating these tests, I also noticed a handful of places where it looked easy to stop using "LegacyBundle_DoNotUseInNewTests". With c36b3b5 and a2b042c there's now 241 places that use those legacy test fixtures, down from 314 places on main.


Lastly, 28b531d, 28b531d, and 54e3a53 update various user-facing documentation and contributor documentation to use other terminology instead of "bundle".

Dependencies

None

Testing

Nothing in particular. This isn't a user-facing change.

Checklist

Make sure you check off the following items. If they cannot be completed, provide a reason.

  • Added Updated tests
  • Ran the ./bin/test script and it succeeded
  • Updated documentation if necessary

@d-ronnqvist d-ronnqvist added the code cleanup Code cleanup *without* user facing changes label Sep 23, 2025
@d-ronnqvist
Copy link
Contributor Author

@swift-ci please test

@d-ronnqvist d-ronnqvist force-pushed the rename-bundle-to-inputs branch from 02138fc to 283f497 Compare September 23, 2025 16:43
@d-ronnqvist
Copy link
Contributor Author

@swift-ci please test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
code cleanup Code cleanup *without* user facing changes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant