Optimize build times by removing SwiftUI export in the module files

[danielsaidi]

I have investigated the insanely slow build times required to generate DocC documentation for SwiftUIX, which takes ~10 minutes on my local M1 Pro Max, and much longer with GitHub Actions.

Turns out that @_exported import SwiftUI in the module files is the main reason, since it causes the entire SwiftUI framework to be included in the generated DocC documentation.

By removing @_exported and adding some then needed import SwiftUI in some files, DocC build times went from ~10 minutes to ~1 minute. This also removes all SwiftUI types from the SwiftUIX documentation.

I understand that you want to export SwiftUI together with SwiftUIX, so that people only have to import SwiftUIX, so I looked for a way to export SwiftUI but omit it from DocC.

This doesn't work, since it causes build warnings for missing symbols:

@_documentation(visibility: internal) // I also tried package
@_exported import SwiftUI

There seems to be some activity regarding this, for instance here: https://forums.swift.org/t/filtering-out-exported-import-symbols-from-symbol-graphs/57022/6

So I guess we need to think about this. This PR removes the export altogether, so please have a look at the implications within the package for doing so (few). But the external implications are pretty huge.

If we decide to keep the export, but can't exclude SwiftUI from DocC, I think we may have a big problem if we want to keep documenting, since it takes a LOT of time and build resources, and causes the documentation to become bloated.

Furthermore, keeping the export means that the expensive CI runs mean we can't integrate DocC into the build pipeline (since it would eat up CI costs).

All in all, this is a discussion regarding what's most important. Exporting the entire SwiftUI to let people only import SwiftUIX, or removing the export to make the build more performant and the generated documentation cleaner.

Perhaps there are some alternatives that I don't see?

[vmanot]

@danielsaidi as discussed, we should probably file a bug report for DocC (this is their mess, not ours). This PR is still good in that it adds missing imports, can you discard removing the @_exported import and merge this?

[danielsaidi]

@danielsaidi as discussed, we should probably file a bug report for DocC (this is their mess, not ours). This PR is still good in that it adds missing imports, can you discard removing the @_exported import and merge this?

I agree, but it's too bad that this stops us from having the master branch build trigger, which would be nice to have in place now that we know how to get the build times down to reasonable and manageable level.

It would be amazing if there'd be a preprocessor macro to help inspecting whether the build is triggered by DocC, to let us conditionally export the symbols.

Do you know of such a way?

[danielsaidi]

@vmanot I have created a couple of shell scripts that make it easy to generate DocC without the SwiftUI export, and have adjusted the GitHub action runner to use this script. This lets us temporarily disable the export while building DocC, with a reverse step for the times we want to build the documentation from a local machine.