Explicit folders on the `codePaths` argument shouldn't be ignored later.
tladesignz opened this issue · comments
Problem Statement
I have code in a pod which I want searched, but BartyCrouch will ignore these files, because they'll contain a "pods" folder in their URL.
Suggested Solution
From user view:
When a folder is added in the codePaths argument, which contains ignored folders, then the files in there should be included anyways.
From developer view:
Only the subfolders of the folders stated in the codePaths argument should be checked against
https://github.com/Flinesoft/BartyCrouch/blob/main/Sources/BartyCrouchKit/FileHandling/CodeFilesSearch.swift#L11
(BTW: This list should be static!)
That method probably needs a ignoredBase parameter, which then is used in truncating the url parameter before the check.
Example Usage
[update.code]
codePaths = ["Pods/MySubprojectPod"]=> This should search all code files below that folder, despite CodeFilesSearch.shouldSkipFile(at:) returning true (today).
Possible Involvement
- I could help with implementation: ✅
- I could help with testing: ✅
@tladesignz Thank you very much for reporting this. We have a similar issue with InfoPlist.strings files getting ignored due to fixed constants that can't be configured to not be ignored via the configuration file. I plan to introduce configuration options for all fixed strings, I can also do that for Pods files so you can override ignoring the entire Pods folder and instead specify your own to ignore. The new config options will have to default to the current values though so there's no break in the behavior.
If what you want is something different and you actually want to change the behavior of codePaths, feel free to post a PR with your exact suggestion though and I will have a look, I'm open to merge that, too. I'm just not sure if I will have the time to implement it (I'm not sure if it's an easy fix or needs some logic refactoring).
Making the ignore list configurable certainly would give a tool to fix my problem.
However, I would still consider the usage counter-intuitive: Even though, I explicitly add a certain folder to get scanned, it gets ignored by default, because one of its parent folders matches the default ignore-list.
As already stated: The ignore-list should only be applied to automatically found sub-folders of given codePaths folders.
I understand that changing that behaviour might break a very small fraction of configurations. However I'd argue, that these were done in error and never fixed because the current implementation hides the problem. There's no situation I can imagine where it does make any sense to add a folder to the codePaths which gets ignored completely, anyway.
This change will be easily spotted and can be easily fixed in such a faulty configuration. After a BartyCrouch updated, your localization source file will contain a whole lot of new strings you didn't expect. Fix: remove the unwanted codePaths folder. Re-build. Done.
So, actually one can argue, that the proposed change in the behaviour of BartyCrouch doesn't break configurations, but finally helps users to spot faulty configurations. That's actually wanted.
I'll contribute a change after my vacation. Happy new year!
@tladesignz I think you got me wrong, I never said that I think your suggestion doesn't make sense or would break things for users, sorry that I wasn't more explicit: I do agree with your assessment that an explicit mention of a (sub)path in the codePaths should not be ignored by global ignores. The global ignores should only happen for subpaths if anything. I'm just not sure if that's easy to implement or not and since I'm planning a larger rewrite anyways, it's not worth fixing for me before that. But feel free to give it a try. 👍
Was actually quite easy to fix. Hope that helps!
Thank you @tladesignz!