@pepicrft Are there plans to fix this? It seems to me that this revision would be useful in large cross-functional teams in which modules are created according to a certain template with optional options

I added it to our bounty program and flagged it as a good-first-time issue to see if anyone wants to pick it up. Unfortunately, it'll take us some time to get to it because there are some other issues in the list that are preventing users from using some Tuist features, and those usually take priority. I can give you pointers if you are interested in tackling it yourself.

Hello, @Ernest0-Production,
Instead of adding resource extensions just on the contrary exclude sources and headers extensions (and some other supporting file extensions) in excluding array. For example, here I exclude .swift, .m, headers and explicitly Info.plist :

resources: [
    .glob(pattern: "MyTarget/**", excluding: "**/{*.{swift,m,h},Info.plist}"),
]

Please, read my full idea around this here: #6032

Hi! Thanks for the advice, but it seems to me that going from the opposite is not a completely correct decision.
It is more logical to specify a list of only those types of resources that need to be bundled, and not those that cannot.

The problem described in your proposal is related to a situation where resources are mixed with code, but even if they are separated, in my opinion, it still makes sense to explicitly set restrictions in the form of file extensions allowed for sources and for resources.

• Folders pattern as paths regulate the structure of the project
• but file extensions pattern also allow you to regulate what the system (xcode) should expect from it

Hey, I would love to tackle this issue, can It get assigned to me?

@Ernest0-Production is there a demo project to test things on from the fixtures that can be used?
@pepicrft if possible can I get those pointers so I can start working on it during the week?

@pepicrft should this be opt-out?
e.g. I understand the warning is a problem if the target is generated from a template (and hence you might want to ignore it there), but I think it's useful if the target is defined "manually"

if its opt-out would something like tuist generate --suppress-warnings work? and basically add that to the logger?

I think two things should be done here.

1. Quiet mode, which removes any output except for an error.
2. Do not consider the absence of files in the specified directory using the glob template to be incorrect behavior

1. Regarding the quiet mode, I think that can be done by wrapping the logger with a TuistLogger object that will have a flag that will be set to skip warnings.
2. Im not sure about the second one since either ways the generate is the one that is supposed to be the one that suppresses the warning and not the tuist init correct me If I am wrong here. But ofc all the commands can have the --suppress-warning flag.

It would be nice to verify the thought process by the maintainers here.