I understand that you do not feel like this is a bug.
However, I still think this is unintuitive:
while I agree that this is technically a directory, inside Xcode, it appears as a file and inside Tuist I can add it directly as a file
I did not explicitely add the xcassets as a file in the resources
I had a wildcard resource glob that, as a side effect, included the xcassetsas a file so I expected that excluding it as a file would remove it
What happened is that it took me quite some time to understand that my *.png rule was the one adding the xcassets to the project resources. I has trouble understanding what was happening because the xcassets was nowhere to be found in my Tuist manifest, and the xcassets was explicitely excluded. I had to remove all rules and put them back in one by one to see that the wildcard PNG rule was the culprit. I just wanted to share this to prevent other people the same fate.
Maybe the problem is the PNG to xcasset conversion rule? When including a .png from a xcassets directory, instead of implicitely and transparently including the xcassets itself (which is a nice feature but can be seen as a weird hidden side effect), how about failing with an error to ask users to explicitely add the xcassets instead? I feel like that approach would match the Swift philosophy more.
This would be a breaking change, so it’s not something we can do without releasing a new major version – for which we have no plans as of now.
Additionally, what would you do when you added the following globs:
*.png
*.xcassets
And you had the following resources:
top.png
Assets.xcassets
\ nested.png
Would you throw an error/warning in this case? I’d say we shouldn’t.
I can see how this is what you’d expect the behavior to be. I’d suggest that we automatically exclusion of expand opaque directories such as .xcassets to .xcassets/**, so we respect the mental model one has for .xcassets. Would you be up to contribute something like this?
Your message made me realise that to be fully coherent, my proposal needs another clause for wildcards as a whole.
So that would be:
in all wildcards like *.png*.jpg etc… ignore all files inside an xcassets (which is a breaking change indeed, and an invisible one)
when explicitly adding a file inside an xcassets with a rule like Icons.xcassets/somefile.png, throw an error asking to add the whole xcassets instead
And I agree with you because the intent of the two globs would be different:
the first one is to add all PNGs outside of the xcassets (since we now always consider them as a whole and never "seez the files inside)
the second one is to add all xcassets as a whole
This is a good idea, that would solve my original issue.
Would I be up, sure, the question would be more do I have the time I can’t promise anything, I’ll look into it if I have some spare time. It doesn’t look to hard to implement, thanks for pointing me to the right file
I can’t promise anything, I’ll look into it if I have some spare time. It doesn’t look to hard to implement, thanks for pointing me to the right file