Rubocop: Support .yaml extension for rubocop config files

[fishermand46]

I created a rubocop.yaml file today to find it had no effect on rubocop's behavior. I think it should support the official (FAQ #1) extension '.yaml' in addition to the old '.yml' (for backwards compatibility sake).

[bbatsov]

Seems that in practice most people are using yml (maybe Rails has something to do with this). I'm fine with supporting both formats, but for me this is one more argument if favour of moving to a Ruby-based config. :-)

[bbatsov]

@jonas054 Any thoughts on this?

[jonas054]

Very little to gain from supporting .rubocop.yaml, just more complexity IMO (for example, what happens when files with both extensions are found). We're already specifying the .rubocop part, so I think we can require the extension to be .yml.

[bbatsov]

Fair enough.

[AlexWayfer]

just more complexity IMO (for example, what happens when files with both extensions are found)

1. Just take the first of them (it's user's fault, not tool's)
2. raise "More then one of configuration files found: #{files.inspect}" if files.size > 1 — is it too complex?

[mikegee]

I think it is a little out of place to disagree about the complexity and maintenance burden, and then not make the PR and offer to support it. I can't keep up with the issues created on this project. It needs all the support it can get.

[AlexWayfer]

I think it is a little out of place to disagree about the complexity and maintenance burden, and then not make the PR and offer to support it.

I don't want to create the PR because the issue about this was closed just because "complexity of supporting". This repo has tests, which simplify supporting features, but no, there is no "make PR if you want", there is "let's don't do this!".

[jonas054]

Also contributing to the complexity of supporting two extensions:

1. Documentation - should we add "or .rubocop.yaml" everywhere that ".rubocop.yml" is mentioned?
2. The todo file generation: a) should we generate .rubocop_todo.yaml in some situations? b) We update .rubocop.yml today with inherit_from: .rubocop_todo.yml. That might need to change too.

I still think it's not worth it.

[FranklinYu]

@jonas054 For question 1, we need to mention .yaml only once. For question 2a, no. .yml is the default. User requiring .yaml will rename the file and update the inheritance anyway. They only do it once per project, not a big deal.

[jonas054]

They only do it once per project, not a big deal.

Plus every time they re-run --auto-gen-config. I remain unconvinced. :slightly_smiling_face:

[FranklinYu]

@jonas054 I think I have some misunderstanding about --auto-gen-config; is it supposed to run frequently? Currently our team only run it once (when we start to use Rubocop in the project), then work to eliminate the .rubocop_todo.yml. I assume this is why we call it TODO. It doesn't feel right to generate it again and again.

[mikegee]

@FranklinYu there's a workflow where a developer works on resolving offenses while looking at the generated .rubocop_todo config, then runs rubocop --auto-gen-config, and looks at the git diff to check their progress.

[FranklinYu]

@mikegee Thank you. This wasn’t our case, probably because there weren’t that many things in .rubocop_todo; but I guess this works for some organization.

Even in this case, I think I can accept both .rubocop_todo.yml and .rubocop_todo.yaml.

I still think it's not worth it.

Not worth what? Development? If so, is PR welcomed? I would totally understand if no one in the organization want to spend time, and this is how community works. If this feature is at least considered reasonable, other developers like me can provide help.

[jonas054]

Not worth what? Development?

No I was thinking about maintenance when I said that. I foresee a number of problems if we allow two different file names for the configuration file.

1. When answering support questions, you can't just say "What's in your .rubocop.yml?" anymore. You'd have to say "What's in your .rubocop.yml or .rubocop.yaml?".
2. If you want to search for RuboCop configuration in a large directory tree, or on GitHub, you'd have to search for two different file names or a pattern, not just for .rubocop.yml.
3. What should happen if both files are found? People will have different opinions on that:
   a) .rubocop.yaml should be silently ignored
   b) .rubocop.yml should be silently ignored
   c) an error should be reported
   d) both files should be read
   e) it should be configurable
4. What if .rubocop.yaml becomes more popular over time? People will request that .rubocop_todo.yaml be generated. Or configurable.

This is what I came up with right now. It's impossible to anticipate all problems and opinions the users will have. So to me, this is a clear case of not enough benefit for the effort. We're introducing complexity, but for what purpose?

[AlexWayfer]

When answering support questions, you can't just say "What's in your .rubocop.yml?" anymore. You'd have to say "What's in your .rubocop.yml or .rubocop.yaml?".

"What's in your RuboCop config file?"

If you want to search for RuboCop configuration in a large directory tree, or on GitHub, you'd have to search for two different file names or a pattern, not just for .rubocop.yml.

.rubocop.* or .rubocop.y{a,}ml

an error should be reported

Of course.

What if .rubocop.yaml becomes more popular over time? People will request that .rubocop_todo.yaml be generated. Or configurable.

It should be by default, as YAML spec says.

It's impossible to anticipate all problems and opinions the users will have.

And that's why we have standards, specs and guidelines. And YAML's standard says that .yaml is single correct file extension.

We're introducing complexity, but for what purpose?

To follow standards. In tool for community standards.

[mikegee]

It should be by default, as YAML spec says.

I can’t find that at https://yaml.org/spec/1.2/spec.html. Please point me in the right direction.

—-
Edit

It is phrased as a recommendation at https://yaml.org/faq.html

[AlexWayfer]

I can’t find that at https://yaml.org/spec/1.2/spec.html. Please point me in the right direction.

The issue-start comment.

It is phrased as a recommendation at https://yaml.org/faq.html

Hm, maybe.

As appeal.

Is it possible to use .yaml in RuboCop? I think, yes.

[FranklinYu]

4. What if .rubocop.yaml becomes more popular over time?

…It means that we made the wrong choice between .yml and .yaml? 😄

I expect .yaml to be mentioned in the documentation only a few times, so most places will still use .yml. If .yaml gets popular even in that case, this means .yaml is significantly superior (which you won't agree).

3. What should happen if both files are found? People will have different opinions on that

Raising an error is decent, but if nobody even wants to maintain this logic: make this “undefined behavior” and ask those “people” to RTFM.

As for why they propose (and I prefer) .yaml over .yml (in case anyone wonders): it's to prevent collision. For example, I can’t tell what’s a .pl file. It’s not just “one more letters”; it’s “use full name”. Using 3 letters or less is to be compatible with DOS. (Anyone still use DOS nowadays?)