Rename "documentation bundle" to "documentation inputs" #1294
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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":
The main bit of updated API is
DocumentationBundle
which was previously aliased toDocumentationContext.Inputs
and documented to be "A collection of the build inputs for a unit of documentation". This PR switches that around so thatDocumentationContext.Inputs
is the primary name andDocumentationBundle
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:
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 contextloadFromDisk(...)
for the test helpers that perform real file system I/Oload(catalog:...)
for the test helper that uses a virtual file systemI 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.
AddedUpdated tests./bin/test
script and it succeeded