Enable Style/FrozenStringLiteralComment

[dduugg]

Why

The # frozen_string_literal: true pragma turns accidental mutation of a string literal into an immediate FrozenError, so it can't quietly corrupt a shared value. It also saves allocations, because each literal becomes one shared frozen object. Nearly every file here already had the pragma, but the cop was disabled, so nothing enforced it on new files.

Config change

• .rubocop.yml: removed the override below (plus its comment):

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

  The cop now runs with the config inherited from rubocop-gusto, which is Enabled: true, EnforcedStyle: always_true. .rubocop_todo.yml had no entry for this cop and is unchanged.

Files that got the pragma (5)

• packwerk-extensions.gemspec
• test/fixtures/skeleton/components/timeline/app/models/graphql.rb
• test/fixtures/skeleton/components/timeline/app/models/graphql/private_thing.rb
• test/fixtures/skeleton/components/timeline/app/models/private_thing.rb
• test/fixtures/skeleton/config/environment.rb

Everything under lib/, bin/, and test/ already had the pragma, and so did Rakefile and Gemfile. In the four fixtures the pragma goes after the existing # typed: sigil, matching every other file in the repo. None of those fixtures contains a string literal. No test depends on their line numbers, and none has a pack_public: true sigil that an extra line could push out of the privacy checker's 5-line scan window.

Exclusions: I added none.

• test/fixtures/minimal/config/environment.rb is an empty file, already excluded from Lint/EmptyFile. The cop skips files with no tokens, so it needs no pragma.
• The tapioca-generated sorbet/rbi/gems/*.rbi files are not in RuboCop's default AllCops/Include, so RuboCop never inspects them.

Runtime fixes

None were needed. The only shipped file whose runtime behavior changes is the gemspec. It passes its literals to Gem::Specification setters and Gem::Requirement/Gem::Version, and none of those mutate their arguments. The four fixtures contain no string literals.

These values are frozen but safe:

• The VIOLATION_TYPE constants.
• Privacy::Package#public_path's 'app/public/' fallback.
• The permitted_keys elements.
• The "\n---\n" separator.

All of them were already frozen on main, because lib/ had the pragma. packwerk only reads them: it uses them as hash keys, calls include?/lstrip/join on them, and interpolates them. The << calls in the validators and in packwerk's PackageTodo append to Arrays, not Strings.

Verification

• Specs: bundle exec rake gave 88 runs, 142 assertions, 0 failures, 0 errors on both main and this branch.
  • Also 88/142/0/0 with RUBYOPT="--enable-frozen-string-literal --debug-frozen-string-literal", which freezes every literal in every loaded file, including gems.
  • Run locally on Ruby 4.0.5, and separately on Ruby 3.3.11 (the minimum supported version).
  • No "literal string will be frozen" warnings under -W:deprecated.
• RuboCop: bundle exec rubocop inspected 67 files with no offenses.
• Sorbet: bundle exec srb tc reported no errors.
• Static sweep: I read every file in lib/, bin/, and test/support, plus the gemspec, Rakefile, and Gemfile, looking for mutating String calls, default-argument buffers, mutated constants, and literals passed to libraries that mutate their arguments. I also checked how packwerk 3.3.1 uses the values these checkers return. I found none.
• Dynamic checks:
  • I ran packwerk's validate, check, and update-todo against scratch Rails apps, both under --debug-frozen-string-literal and with every literal frozen. The apps exercised every checker message, strict mode for all four checkers, both the layers and architecture_layers configs, cache/parallel mode, and every validator error branch, including the three that no spec covers. No FrozenError.
  • The gemspec loads, validates, and builds with gem build and rake build, and it installs cleanly with its literals frozen.
• Fresh Eyes: a local pre-push review reported 0 blockers, 0 majors, 0 minors, and 0 info findings.