Should we enable the FrozenStringLiteralComment lint?

[mokagio]

While working on a private projects, we noticed that .rubocop.yml disables the FrozenStringLiteralComment lint.

There is a rationale for that setting, but I wonder whether it's time to reconsider it and adopt the standard.

One case against it is that we don't know what Fastlane might be doing under the hood to the constants we pass it. We even run into at least one instance of a crash due to that, see wordpress-mobile/WordPress-iOS#18417. Even with that, I still think we'd be better off enabling the lint and discover and fix possible issues in the tooling.

What do you think?

[AliSoftware]

I say let's give it a try.

There's indeed a risk that doing so would make some actions to crash because their implementations assumed mutability of some variables (recent example of similar case: p1736258590769169-slack-C029BMLUGRX).

But at the same time we won't find those instances until we try to unable FrozenStringLiterals to surface those.

So I say at some point we're gonna have to take a deep breath and be ready to "move fast and break things" rather than never doing it out of extra caution and fear of introducing crashes (which should be easy to fix quickly … but will still temporarily create annoyances and blockers for eg devs doing release management if they see their MC releases CI jobs fail due to that and will have to ping us to unblock them, which is the reason why we refrained for attempting this change so far, but gotta take the jump at some point anyway)