Support treating arbitrary directories as files in Buildable Folder resolution

Ideas
1

With this recent PR, opaque directories such as .xcassets directories are treated as files rather than directories. I’m wondering if it’s possible to support similarly treating an arbitrary directory as a file? This was possible when using resources: rather than buildableFolders:, by passing FileElement.folderReference(path: "Some/Directory”) instead of ”Some/Directory”. But while resources:took arguments of type ResourceFileElements, buildableFolders only takes a BuildableFolder, which can only be created from a string or Path, not a FileElement.

This would be valuable to my team– without going into too much detail, we have an external Git Submodule which contains nested subdirectories of resources, and it’s ideal for us to preserve the underlying directory structure when accessing these files.

A related but slightly different request would be the ability to add an arbitrary file to the BuildableFolders array, with it being treated the same as an opaque folder. I understand that in practical terms this would likely be functionally the same as just passing single files via resources:, but it would be nice from a readability perspective to have all resources in one place.

2

Hi @sphanley :waving_hand:

Unfortunately this isn’t something we can support through buildableFolders. Under the hood, buildableFolders maps to Xcode’s PBXFileSystemSynchronizedRootGroup, which doesn’t have a concept of folder references. Xcode automatically syncs the contents of the directory and natively knows how to handle known opaque directories like .xcassets or .bundle (that’s what PR #9683 fixed on Tuist’s side, our internal file resolution for synthesized accessors). But for an arbitrary directory, there’s no way to tell Xcode “treat this as opaque” within a synchronized group.

For your use case with the Git submodule where you need to preserve the directory structure, resources: [.folderReference(path: "Some/Directory")] is still the right approach.

You can use both APIs in the same target, so you could use buildableFolders for your sources and most resources, and resources: with .folderReference for the specific directories where you need the structure preserved.

3

Got it! That’s what we’re doing currently, so I guess it’s what we’ll have to continue with. I didn’t realize that Xcode only supported opaque directories with known extensions, but that totally makes sense. Thanks for the info!