Enable Style/FrozenStringLiteralComment

[dduugg]

Why

With # frozen_string_literal: true, an accidental in-place change to a string literal raises a FrozenError right where it happens, rather than quietly changing shared state. The pragma also means each literal is allocated once instead of every time the line runs. On Ruby 3.4+, files without the pragma already emit "literal string will be frozen in the future" deprecation warnings when they mutate a literal, so turning the cop on now keeps us ahead of that.

Config change

.rubocop.yml: removed this block:

# Disabling for now until it's clearer why we want this
Style/FrozenStringLiteralComment:
  Enabled: false

With it gone, the cop picks up EnforcedStyle: always_true from the inherited rubocop-gusto config/default.yml. .rubocop_todo.yml had no entry for this cop, so it is unchanged.

Files changed

• 40 files got the pragma: everything under lib/, plus bin/packs, Gemfile, Rakefile, packs.gemspec, spec/packs_spec.rb, spec/packs/private/cli_spec.rb and spec/verify_docs_spec.rb.
• 6 more files already had it (bin/rubocop, bin/tapioca, sorbet/tapioca/require.rb, spec/spec_helper.rb, and two interactive CLI specs). That makes 46, the number of files rubocop inspects.
• No exclusions were added. The only generated Ruby is sorbet/rbi/**/*.rbi, which rubocop already skips.
• In bin/packs, the pragma goes on line 3, after the shebang and # typed: strict. Ruby still honors it there.

Runtime fixes

None were needed. No spec failed. A static review of every string literal in lib/ and bin/ found none that reaches an in-place String mutation. Every << in lib/ appends to an Array, and the gems that receive our literals (Thor, tty-prompt/tty-reader, Pastel, Rainbow, CSV, parse_packwerk, code_ownership, packwerk) either copy them or never change them.

Heads-up for downstream code: a few public methods now return frozen Strings. These are the <<~MSG heredocs without interpolation in Packs::UserEventLogger#after_make_public and #after_add_dependency, the literal in #documentation_link, and Packs::Private.rename_pack. A custom logger that did super << "..." would now raise FrozenError. Nothing in this repo or its docs does that, and a GitHub code search turned up no such overrides. It was already deprecated too: on main, that pattern warns on Ruby 3.4+.

Verification

• Specs: origin/main gave 119 examples, 0 failures. This branch gives 119 examples, 0 failures on Ruby 4.0.7 and on 3.3.11, the lowest version in the CI matrix. Those runs used -W:deprecated --debug-frozen-string-literal and produced no chilled-string warnings or FrozenErrors. The suite also passes with RUBYOPT=--enable-frozen-string-literal.
• Rubocop: 46 files inspected, no offenses. srb tc has no errors.
• Static sweep:
  • Checked with Prism that the pragma takes effect in every tracked Ruby file.
  • Listed all 531 string-literal nodes in lib/ and bin/ and traced each one to what consumes it. That covered method return values, default arguments, Hash and Array values, and arguments handed to gems. For the gems, I read the source of the exact locked versions.
  • required_ruby_version is >= 3.3, so interpolated strings stay unfrozen.
• Dynamic checks: specs don't cover everything, so the uncovered paths were run by hand on Ruby 4.0.7 and 3.3.11 against a fixture app, with the output compared to main.
  • 71 bin/packs CLI invocations: every subcommand, help for all 16 commands, and the error paths.
  • 21 interactive-mode scenarios through TTY::Prompt::Test, plus real-PTY runs of the menu, Rename, Create and Ctrl-C.
  • Direct calls to the private helpers.
  • gem build and rake -T.
  • stdout/stderr and the resulting files matched main.
• Fresh Eyes local review: 0 blockers, 0 major, 0 minor.

Checklist

• I bumped the gem version (or don't need to) 💎 (no bump needed: this is a lint/config change with no intended behavior change)