The behavior of RuboCop can be controlled via the.rubocop.ymlconfiguration file. It makes it possible to enable/disable certain cops(checks) and to alter their behavior if they accept any parameters. The filecan be placed in your home directory, XDG config directory, or in some projectdirectory.
The file has the following format:
inherit_from: ../.rubocop.ymlStyle/Encoding: Enabled: falseLayout/LineLength: Max: 99
Qualifying cop name with its type, e.g., Style , is recommended,but not necessary as long as the cop name is unique across all types. |
Config file locations
RuboCop will start looking for the configuration file in the directorywhere the inspected file is and continue its way up to the root directory.
If it cannot be found until reaching the project’s root directory, then it willbe searched for in the .config directory of the project rootand the user’s global config locations. The user’s global config locations consist of adotfile or a config file inside the XDG Base Directoryspecification.
.config/.rubocop.yml
or.config/rubocop/config.yml
at the project root~/.rubocop.yml
$XDG_CONFIG_HOME/rubocop/config.yml
(expands to~/.config/rubocop/config.yml
if$XDG_CONFIG_HOME
is not set)
If both files exist, the dotfile will be selected.
As an example, if RuboCop is invoked from inside /path/to/project/lib/utils
,then RuboCop will use the config as specified inside the first of the followingfiles:
/path/to/project/lib/utils/.rubocop.yml
/path/to/project/lib/.rubocop.yml
/path/to/project/.rubocop.yml
/path/to/project/.config/.rubocop.yml
/path/to/project/.config/rubocop/config.yml
/.rubocop.yml
~/.rubocop.yml
~/.config/rubocop/config.yml
All the previous logic does not apply if a specific configuration file is passedon the command line through the --config flag. In that case, the resolvedconfiguration file will be the one passed to the CLI. |
Inheritance
All configuration inherits from RuboCop’s default configuration (See"Defaults").
RuboCop also supports inheritance in user’s configuration files. The most commonexample would be the .rubocop_todo.yml
file (See "Automatically GeneratedConfiguration" below).
Settings in the child file (that which inherits) override those in the parent(that which is inherited), with the following caveats.
Inheritance of hashes vs. other types
Configuration parameters that are hashes, for example PreferredMethods
inStyle/CollectionMethods
, are merged with the same parameter in the parentconfiguration. This means that any key-value pairs given in child configurationoverride the same keys in parent configuration. Giving ~
, YAML’srepresentation of nil
, as a value cancels the setting of the correspondingkey in the parent configuration. For example:
Style/CollectionMethods: Enabled: true PreferredMethods: # No preference for collect, keep all others from default config. collect: ~
Other types, such as AllCops
/ Include
(an array), are overridden by thechild setting.
Arrays override because if they were merged, there would be no way toremove elements in child files.
However, advanced users can still merge arrays using the inherit_mode
setting.See "Merging arrays using inherit_mode" below.
Inheriting from another configuration file in the project
The optional inherit_from
directive is used to include configurationfrom one or more files. This makes it possible to have the commonproject settings in the .rubocop.yml
file at the project root, andthen only the deviations from those rules in the subdirectories. Thefiles can be given with absolute paths or paths relative to the filewhere they are referenced. The settings after an inherit_from
directive override any settings in the file(s) inherited from. Whenmultiple files are included, the first file in the list has the lowestprecedence and the last one has the highest. The format for multipleinheritance is:
inherit_from: - ../.rubocop.yml - ../conf/.rubocop.yml
inherit_from
also accepts a glob, for example:
inherit_from: - packages/*/.rubocop_todo.yml
The example above is one potential use-case: allowing components within your repo to organize their own .rubocop_todo.yml
files.
Inheriting configuration from a remote URL
The optional inherit_from
directive can contain a full url to a remotefile. This makes it possible to have common project settings stored on a httpserver and shared between many projects.
The remote config file is cached locally and is only updated if:
The file does not exist.
The file has not been updated in the last 24 hours.
The remote copy has a newer modification time than the local copy.
You can inherit from both remote and local files in the same config and thesame inheritance rules apply to remote URLs and inheriting from localfiles where the first file in the list has the lowest precedence and thelast one has the highest. The format for multiple inheritance using URLs is:
inherit_from: - http://www.example.com/rubocop.yml - ../.rubocop.yml
You can inherit from a repo with basic auth that is authorized to access the repo as follow:
inherit_from: - http://<user_name>:<password>@raw.github.com/example/rubocop.yml
A GitHub personal access tokencan also be configured as follow:
inherit_from: - http://<personal_access_token>@raw.github.com/example/rubocop.yml
Inheriting configuration from a dependency gem
The optional inherit_gem
directive is used to include configuration fromone or more gems external to the current project. This makes it possible toinherit a shared dependency’s RuboCop configuration that can be used frommultiple disparate projects.
Configurations inherited in this way will be essentially prepended to theinherit_from
directive, such that the inherit_gem
configurations will beloaded first, then the inherit_from
relative file paths will be loaded(overriding the configurations from the gems), and finally the remainingdirectives in the configuration file will supersede any of the inheritedconfigurations. This means the configurations inherited from one or more gemshave the lowest precedence of inheritance.
The directive should be formatted as a YAML Hash using the gem name as thekey and the relative path within the gem as the value:
inherit_gem: my-shared-gem: .rubocop.yml cucumber: conf/rubocop.yml
An array can also be used as the value to include multiple configuration filesfrom a single gem:
inherit_gem: my-shared-gem: - default.yml - strict.yml
If the shared dependency is declared using a BundlerGemfile and the gem was installed using bundle install , it would benecessary to also invoke RuboCop using Bundler in order to find thedependency’s installation path at runtime: |
$ bundle exec rubocop <options...>
Merging arrays using inherit_mode
The optional directive inherit_mode
specifies which configuration keys thathave array values should be merged together instead of overriding the inheritedvalue.
This applies to explicit inheritance using inherit_from
as well as implicitinheritance from the default configuration.
Given the following config:
# .rubocop.ymlinherit_from: - shared.ymlinherit_mode: merge: - ExcludeAllCops: Exclude: - 'generated/**/*.rb'Style/For: Exclude: - bar.rb
# .shared.ymlStyle/For: Exclude: - foo.rb
The list of Exclude
s for the Style/For
cop in this example will be['foo.rb', 'bar.rb']
. Similarly, the AllCops:Exclude
list will contain allthe default patterns plus the generated/**/*.rb
entry that was added locally.
The directive can also be used on individual cop configurations to overridethe global setting.
inherit_from: - shared.ymlinherit_mode: merge: - ExcludeStyle/For: inherit_mode: override: - Exclude Exclude: - bar.rb
In this example the Exclude
would only include bar.rb
.
Pre-processing
Configuration files are pre-processed using the ERB templating mechanism. Thismakes it possible to add dynamic content that will be evaluated when theconfiguration file is read. For example, you could let RuboCop ignore all filesignored by Git.
AllCops: Exclude: <% `git status --ignored --porcelain`.lines.grep(/^!! /).each do |path| %> - <%= path.sub(/^!! /, '').sub(/\/$/, '/**/*') %> <% end %>
Defaults
The file config/default.yml under the RuboCop home directory contains thedefault settings that all configurations inherit from. Project and personal.rubocop.yml
files need only make settings that are different from thedefault ones. If there is no .rubocop.yml
file in the project, home or XDGdirectories, config/default.yml
will be used.
Including/Excluding files
RuboCop does a recursive file search starting from the directory it isrun in, or directories given as command line arguments. Files thatmatch any pattern listed under AllCops
/Include
and extensionlessfiles with a hash-bang (#!
) declaration containing one of the knownruby interpreters listed under AllCops
/RubyInterpreters
areinspected, unless the file also matches a pattern inAllCops
/Exclude
. Hidden directories (i.e., directories whose namesstart with a dot) are not searched by default.
Here is an example that might be used for a Rails project:
AllCops: Exclude: - 'db/**/*' - 'config/**/*' - 'script/**/*' - 'bin/{rails,rake}' - !ruby/regexp /old_and_unused\.rb$/# other configuration# ...
When inspecting a certain directory(or file)given as RuboCop’s command line arguments,patterns listed under AllCops / Exclude are also inspected.If you want to apply AllCops / Exclude rules in this circ*mstance,add --force-exclusion to the command line argument. |
Here is an example:
# .rubocop.ymlAllCops: Exclude: - foo.rb
If foo.rb
specified as a RuboCop’s command line argument, the result is:
# RuboCop inspects foo.rb.$ bundle exec rubocop foo.rb# RuboCop does not inspect foo.rb.$ bundle exec rubocop --force-exclusion foo.rb
Path relativity
In .rubocop.yml
and any other configuration file beginning with .rubocop
,files, and directories are specified relative to the directory where theconfiguration file is. In configuration files that don’t begin with .rubocop
,e.g. our_company_defaults.yml
, paths are relative to the directory whererubocop
is run.
This affects cops that have customisable paths: if the default is db/migrate/*.rb
,and the cop is enabled in db/migrate/.rubocop.yml
, the path will need to beexplicitly set as *.rb
, as the default will look for db/migrate/db/migrate/*.rb
.This is unlikely to be what you wanted.
Unusual files, that would not be included by default
RuboCop comes with a comprehensive list of common ruby file names andextensions. But, if you’d like RuboCop to check files that are not included bydefault, you’ll need to pass them in on the command line, or to add entries forthem under AllCops
/Include
. Remember that your configuration files overrideRuboCops’s defaults. In the following example, we want to includefoo.unusual_extension
, but we also must copy any other patterns we need fromthe overridden default.yml
.
AllCops: Include: - foo.unusual_extension - '**/*.rb' - '**/*.gemfile' - '**/*.gemspec' - '**/*.rake' - '**/*.ru' - '**/Gemfile' - '**/Rakefile'
This behavior of Include
(overriding default.yml
) was introduced in0.56.0via #5882. This change allowspeople to include/exclude precisely what they need to, without the defaultsgetting in the way.
Another example, using inherit_mode
inherit_mode: merge: - IncludeAllCops: Include: - foo.unusual_extension
See "Merging arrays using inherit_mode" above.
Deprecated patterns
Patterns that are just a file name, e.g. Rakefile
, will matchthat file name in any directory, but this pattern style is deprecated. Thecorrect way to match the file in any directory, including the current, is**/Rakefile
.
The pattern config/**
will match any file recursively underconfig
, but this pattern style is deprecated and should be replaced byconfig/**/*
.
Include
and Exclude
are relative to their directory
The Include
and Exclude
parameters are special. They arevalid for the directory tree starting where they are defined. They are notshadowed by the setting of Include
and Exclude
in other .rubocop.yml
files in subdirectories. This is different from all other parameters, whofollow RuboCop’s general principle that configuration for an inspected fileis taken from the nearest .rubocop.yml
, searching upwards.
This behaviorwill be overridden if you specify the --ignore-parent-exclusion command lineargument. |
Cop-specific Include
and Exclude
Cops can be run only on specific sets of files when that’s needed (forinstance you might want to run some Rails model checks only on files whosepaths match app/models/*.rb
). All cops support theInclude
param.
Rails/HasAndBelongsToMany: Include: - app/models/*.rb
Cops can also exclude only specific sets of files when that’s needed (forinstance you might want to run some cop only on a specific file). All cops support theExclude
param.
Rails/HasAndBelongsToMany: Exclude: - app/models/problematic.rb
Generic configuration parameters
In addition to Include
and Exclude
, the following parameters are availablefor every cop.
Enabled
Specific cops can be disabled by setting Enabled
to false
for that specific cop.
Layout/LineLength: Enabled: false
Most cops are enabled by default. Cops, introduced or significantly updatedbetween major versions, are in a special pending status (read more in"Versioning"). Some cops, configured the above Enabled: false
in config/default.yml,are disabled by default.
The cop enabling process can be altered by setting DisabledByDefault
orEnabledByDefault
(but not both) to true
. These settings override the default for allcops to disabled or enabled, except Lint/Syntax
which is always enabled,regardless of the cops' default values (whether enabled, disabled or pending).
AllCops: DisabledByDefault: true
All cops except Lint/Syntax
are then disabled by default. Only cops appearing in userconfiguration files with Enabled: true
will be enabled; every other cop willbe disabled without having to explicitly disable them in configuration. It isalso possible to enable entire departments by adding for example
Style: Enabled: true
All cops in the Style
department are then enabled.
If a department is disabled, cops in that department can still be individuallyenabled, and that setting overrides the setting for its department in the sameconfiguration file and in any inherited file.
inherit_from: config_that_disables_the_metrics_department.ymlMetrics/MethodLength: Enabled: trueStyle: Enabled: falseStyle/Alias: Enabled: true
Severity
Each cop has a default severity level based on which department it belongsto. The level is normally warning
for Lint
and convention
for all theothers, but this can be changed in user configuration. Cops can customize theirseverity level. Allowed values are info
, refactor
, convention
, warning
, error
and fatal
.
Cops with severity info
will be reported but will not cause rubocop
to returna non-zero value.
There is one exception from the general rule above and that is Lint/Syntax
, aspecial cop that checks for syntax errors before the other cops are invoked. Itcannot be disabled and its severity (fatal
) cannot be changed inconfiguration.
Lint: Severity: errorMetrics/CyclomaticComplexity: Severity: warning
Details
Individual cops can be embellished with extra details in offense messages:
Layout/LineLength: Details: >- If lines are too short, text becomes hard to read because you must constantly jump from one line to the next while reading. If lines are too long, the line jumping becomes too hard because you "lose the line" while going back to the start of the next line. 80 characters is a good compromise.
These details will only be seen when RuboCop is run with the --extra-details
flag or if ExtraDetails
is set to true in your global RuboCop configuration.
AutoCorrect
Cops that support the --autocorrect
option offer flexible settings for autocorrection.These settings can be specified in the configuration file as follows:
always
contextual
disabled
always (Default)
This setting enables autocorrection always by default. For backward compatibility, true
is treated the same as always
.
Style/PerlBackrefs: AutoCorrect: always # or true
contextual
This setting enables autocorrection when launched from the rubocop
command, but it is not available through LSP.e.g., rubocop --lsp
, rubocop --editor-mode
, or a program where RuboCop::LSP.enable
has been applied.
Inspections via the command line are treated as code that has been finalized.
Style/PerlBackrefs: AutoCorrect: contextual
This setting prevents autocorrection during editing in the editor. e.g, with textDocument/formatting
LSP method.However workspace/executeCommand
LSP method, which is triggered by intentional user actions, respects the user’s intention for autocorrection.
Additionally, for cases like Metrics
cops where the highlight range extends over the entire body of classes, modules, methods, or blocksoffending range will be confined to only name. This approach helps to avoid redundant and noisy offenses in editor display.
disabled
This setting disables autocorrection. For backward compatibility, false
is treated the same as disabled
.
Style/PerlBackrefs: AutoCorrect: disabled # or false
Common configuration parameters
There are some configuration parameters that are shared by many cops, with the same behavior.
IgnoredMethods
Cops that evaluate methods can often be configured to ignore certain methods. Both strings andregular expressions can be used. For example:
Metrics/BlockLength: IgnoredMethods: - refine - !ruby/regexp /\b(class|instance)_methods\b/
Setting the target Ruby version
Some checks are dependent on the version of the Ruby interpreter which theinspected code must run on. For example, enforcing using Ruby 2.6+ endlessranges foo[n..]
rather than foo[n..-1]
can help make your code shorter andmore consistent… unless it must run on e.g. Ruby 2.5.
Users may let RuboCop know the oldest version of Ruby which your projectsupports with:
AllCops: TargetRubyVersion: 2.5
When ParserEngine: parser_prism is specified, TargetRubyVersion mustbe set to 3.3 or higher. |
If a TargetRubyVersion
is not specified in your config, then RuboCop willcheck your project for a series of other files where the Ruby version may bespecified already. The files that will be checked are (in this order):*.gemspec
, .ruby-version
, .tool-versions
, and Gemfile.lock
.
If a target Ruby version cannot be found via any of the above sources, then adefault target Ruby version will be used.
Finding target Ruby in a *.gemspec
file
In order for RuboCop to parse a *.gemspec
file’s required_ruby_version
, theRuby version must be specified using one of these syntaxes:
a string range, e.g.
'~> 3.2.0'
or'>= 3.2.2'
an array of strings, e.g.
['>= 3.0.0', '< 3.4.0']
a
Gem::Requirement
, e.g.Gem::Requirement.new('>= 3.1.2')
If a *.gemspec
file specifies a range of supported Ruby versions via any ofthese means, then the greater of the following Ruby versions will be used:
the lowest Ruby version that is compatible with your specified range
the lowest version of Ruby that is still supported by your version of RuboCop
If a *.gemspec
file defines its required_ruby_version
dynamically (e.g. byreading from a .ruby-version
file, via an environment variable, referencing aconstant or local variable, etc), then RuboCop will not detect that Rubyversion, and will instead try to find a target Ruby version elsewhere.
Setting the parser engine
The parser engine configuration was introduced in RuboCop 1.62. Thisexperimental feature has been under consideration for a while. |
RuboCop allows switching the backend parser by specifying eitherparser_whitequark
or parser_prism
as the value for the ParserEngine
.
Here are the parsers used as backends for each value:
ParserEngine: parser_whitequark
… https://github.com/whitequark/parserParserEngine: parser_prism
… https://github.com/ruby/prism (Prism::Translation::Parser
)
By default, parser_whitequark
is implicitly used.
parser_whitequark
can analyze source code from Ruby 2.0 and above:
AllCops: ParserEngine: parser_whitequark
parser_prism
can analyze source code from Ruby 3.3 and above:
AllCops: ParserEngine: parser_prism TargetRubyVersion: 3.3
parser_prism
tends to perform analysis faster than parser_whitequark
.
Since the support for Prism is experimental, it is not included inRuboCop’s runtime dependencies. If running RuboCop through Bundler, please addgem 'prism' to your Gemfile : |
gem 'prism'
There are some incompatibilities with parser_whitequark
in parser_prism
,which is the main reason why the support for it is considered experimental.We’re working with Prism’s team to address those. You can track the outstandingknown issues in Prism that affect RuboCophere.
Automatically Generated Configuration
If you have a code base with an overwhelming amount of offenses, it canbe a good idea to use rubocop --auto-gen-config
, which creates.rubocop_todo.yml
and adds inherit_from: .rubocop_todo.yml
in your.rubocop.yml
. The generated file .rubocop_todo.yml
containsconfiguration to disable cops that currently detect an offense in thecode by changing the configuration for the cop, excluding the offendingfiles, or disabling the cop altogether once a file count limit has beenreached.
By adding the option --exclude-limit COUNT
, e.g., rubocop--auto-gen-config --exclude-limit 5
, you can change how many files areexcluded before the cop is entirely disabled. The default COUNT is 15.If you don’t want the cop to be entirely disabled regardless of thenumber of files, use the --no-exclude-limit
option, e.g.,rubocop --auto-gen-config --no-exclude-limit
.
The next step is to cut and paste configuration from .rubocop_todo.yml
into .rubocop.yml
for everything that you think is in line with your(organization’s) code style and not a good fit for a todo list. Payattention to the comments above each entry. They can reveal configurationparameters such as EnforcedStyle
, which can be used to modify thebehavior of a cop instead of disabling it completely.
Then you can start removing the entries in the generated.rubocop_todo.yml
file one by one as you work through all the offensesin the code. You can also regenerate your .rubocop_todo.yml
usingthe same options by running rubocop --regenerate-todo
.
Another way of silencing offense reports, aside from configuration, isthrough source code comments. These can be added manually orautomatically. See "Disabling Cops within Source Code" below.
The cops in the Metrics
department will by default get Max
parametersgenerated in .rubocop_todo.yml
. The value of these will be just high enoughso that no offenses are reported the next time you run rubocop
. If youprefer to exclude files, like for other cops, add --auto-gen-only-exclude
when running with --auto-gen-config
. It will still change the maximum if thenumber of excluded files is higher than the exclude limit.
Some cops have a configurable option named EnforcedStyle
.By default, when generating the .rubocop_todo.yml
, if one style is usedfor all files, these cops will add the settings for the style being used.If you want to excluded on a file-by-file basis,add the --no-auto-gen-enforced-style
option along with --auto-gen-config
.
Updating the configuration file
When you update RuboCop version, sometimes you need to change .rubocop.yml
.If you use mry, you can update .rubocop.yml
to latest version automatically.
$ gem install mry# Update to latest version$ mry .rubocop.yml# Update to specified version$ mry --target=0.48.0 .rubocop.yml
See https://github.com/pocke/mry for more information.
Disabling Cops within Source Code
One or more individual cops can be disabled locally in a section of afile by adding a comment such as
# rubocop:disable Layout/LineLength, Style/StringLiterals[...]# rubocop:enable Layout/LineLength, Style/StringLiterals
You can also disable entire departments by giving a department name in the comment.
# rubocop:disable Metrics, Layout/LineLength[...]# rubocop:enable Metrics, Layout/LineLength
You can also disable all cops with
# rubocop:disable all[...]# rubocop:enable all
In cases where you want to differentiate intentionally-disabled cops vs. copsyou’d like to revisit later, you can use rubocop:todo
as an alias ofrubocop:disable
.
# rubocop:todo Layout/LineLength, Style/StringLiterals[...]# rubocop:enable Layout/LineLength, Style/StringLiterals
One or more cops can be disabled on a single line with an end-of-linecomment.
for x in (0..19) # rubocop:disable Style/For
If you want to disable a cop that inspects comments, you can do so byadding an "inner comment" on the comment line.
# coding: utf-8 # rubocop:disable Style/Encoding
Running rubocop --autocorrect --disable-uncorrectable
willcreate comments to disable all offenses that can’t be automaticallycorrected.
Do not write anything other than cop name in the disabling comment. E.g.:
# rubocop:disable Layout/LineLength --This is a bad comment that includes other than cop name.
Temporarily enabling cops in source code
In a similar way to disabling cops within source code, you can also temporarily enable specificcops if you want to enforce specific rules for part of the totality of a file.
Let’s use the cop Style/AsciiComments
, which is by default Enabled: false
. If you want aspecific file to have ASCII-only comments to be compatible with some specific post-processing.
# rubocop:enable Style/AsciiComments# If applicable, leave a comment to others explaining the rationale:# We need the comments to remain ASCII only for compatibility with lib/post_processor.rbclass Restaurant # This comment has to be ASCII-only because of the rubocop:enable directive def menu return dishes.map(&:humanize) endend
You can also enforce the same for part of a file by disabling the cop afterwards
class Dish def humanize return [ "Delicious #{self.name}" *ingredients ].join("\n") endend# rubocop:enable Style/AsciiComments# If applicable, leave a comment to others explaining the rationale:# We need the comments to remain ASCII only for compatibility with lib/post_processor.rbclass Restaurant # This comment has to be ASCII-only because of the rubocop:enable directive def menu return dishes.map(&:humanize) endend# rubocop:disable Style/AsciiCommentsclass Ingredient # Notice how the comment below is non-ASCII # Gets rid of odd characters like 😀, def sanitize self.name.gsub(/[^a-z]/, '') endend
Setting the style guide URL
You can specify the base URL of the style guide using StyleGuideBaseURL
.If specified under AllCops
, all cops are targeted.
AllCops: StyleGuideBaseURL: https://rubystyle.guide
StyleGuideBaseURL
is combined with StyleGuide
specified to the cop.
Lint/UselessAssignment: StyleGuide: '#underscore-unused-vars'
The style guide URL is https://rubystyle.guide#underscore-unused-vars.
If specified under a specific department, it takes precedence over AllCops
.The following is an example of specifying Rails
department.
Rails: StyleGuideBaseURL: https://rails.rubystyle.guide
Rails/TimeZone: StyleGuide: '#time'
The style guide URL is https://rails.rubystyle.guide#time.
Setting the documentation URL
You can specify the base URL of the documentation using DocumentationBaseURL
.If specified under AllCops
, all cops are targeted.
AllCops: DocumentationBaseURL: https://docs.rubocop.org/rubocop
If specified under a specific department, it takes precedence over AllCops
.The following is an example of specifying Rails
department.
Rails: DocumentationBaseURL: https://docs.rubocop.org/rubocop-rails
By default, documentation is expected to be served as HTML but if you preferto use something else like markdown you can set DocumentationExtension
.
With markdown as the documentation format you are able to host it directly throughGitHub without having to own a domain or using GitHub Pages. The rubocop-sorbet
extension is an example of this, its docs are availablehere.
Sorbet: DocumentationBaseURL: https://github.com/Shopify/rubocop-sorbet/blob/main/manual DocumentationExtension: .md
Enable checking Active Support extensions
Some cops for checking specified methods (e.g. Style/HashExcept
) supports Active Support extensions.This is off by default, but can be enabled by the ActiveSupportExtensionsEnabled
option.
AllCops: ActiveSupportExtensionsEnabled: true
Opting into globally frozen string literals
Ruby continues to move into the direction of having all string literals frozen by default.Ruby 3.4 for example will show a warning if a non-frozen string literal from a file withoutthe frozen string literal magic comment gets modified. By starting ruby with the environmentvariable RUBYOPT
set to --enable=frozen-string-literal
you can opt into that behaviour today.For RuboCop to provide accurate analysis you must also configure the StringLiteralsFrozenByDefault
option.
AllCops: StringLiteralsFrozenByDefault: true