Explicit folders on the `codePaths` argument shouldn't be ignored later. about bartycrouch HOT 5 CLOSED

@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).

from bartycrouch.

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!

from bartycrouch.

@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. 👍

from bartycrouch.

Was actually quite easy to fix. Hope that helps!

from bartycrouch.

Fixed via #233 and #240. 🎉

Thank you @tladesignz!

from bartycrouch.