DocC fails when type/framework/package names collide

When the package, framework, and a type have basically the same name, how do I get DocC to render my custom landing and type pages instead of the defaults?

Sometimes I get my landing page to render, sometimes the data type's, never both, often neither

Some readers want more of the story:


Use case:

My package is named SlothWatcher. One of the source files is SlothWatcher.swift, which implements enum SlothWatcher, which serves as a namespace for various constants and functions.

I think it's totally reasonable (and common?) to:

  • Name the package SlothWatcher.
  • Name the backbone namespace enum SlothWatcher.
  • Name the file defining the backbone namespace SlothWatcher.swift

Enter DocC

Now I want DocC to generate documentation. DocC adds some requirements, which are all or some combination of:

  • The docc documentation catalog must be named SlothWatcher.docc.
  • The landing page for the documentation catalog, if overriden, must be named SlothWatcher.md.
  • The first line of that file must be # SlothWatcher (name in double-backticks).
  • All documentation referring to the enum docs must use SlothWatcher/SlothWatcher. Certainly in body text, and I've tried it both ways as the header for the enum extension.
  • If there's a naming rule for the enum extension file, I haven't found it. (Other than that you can't easily put a slash into a file name.)

I've lost track. Some of these may not be required at all, given that Xcode defaults none of them.

How, if at all, can I get this into working order?

I think it's totally reasonable (and common?) to:

  • Name the package SlothWatcher.
  • Name the backbone namespace enum SlothWatcher.

Reasonable: Yes! A good idea right now: No )-:

Using the same identifier for the module name and a root type within that module is a known issue in Swift itself. This is a hard problem to fix and that fix may require new syntax. Given that, my advice is that you not do this.

Once there’s a fix for the Swift bug you should revisit the DocC side of this.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I see. I should change the name of a library known and used by thousands of people, and/or rename the service within that library breaking hundreds of apps... all to fix a bug in DocC.

Seriously guys, "Don't do that" is NOT an acceptable answer.

It’s your library, you get to make the final decision here. The way I see it you have to trade off between:

  • Inconveniencing your current users

  • Being compatible with current versions of DocC

That trade-off will be different for each developer who hits this problem, and my initial answer was based on the info provided by the original poster on this thread.

Still, be aware that this isn’t just a problem with DocC. The bug I referenced affects day-to-day Swift development as well.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

DocC fails when type/framework/package names collide
 
 
Q