Thanks for requesting my review. I'm somewhat nervous about adding additional linters to the default_linters since these constitute breaking changes: packages that use lintr's default_linters today may start failing tomorrow if this is merged (this happened when T/F linter was added to the defaults for example).

Nonetheless, if we set up an issue/project to define the changes we want to make before the next big release, and include "expand the default_linters to be consistent with tidyverse style-guidelines", I'm happy for this change to go through.

There are a number of other big changes happening to lintr at the moment, so it may make sense to document the plans for leading-in to lintr-v3. WDYT @jimhester

I think there are enough changes we can make the next release a compatibility breaking one and add some new default linters.

One thing we could do (separate from this PR) is provide a way to easily opt into the previous default linters.

@jimhester That sounds like a good idea.
What about an option lintr.defaults maybe containing a version number or something?

What about an option lintr.defaults maybe containing a version number or something?

I would say, not a good idea. I think we want to maintain only one set of defaults in the long run -- our recommended defaults. The other behavior is just to help with back-compatibility in the short term. Eventually, people using it should migrate to using the recommended defaults, or adjusting their code to their own preferred defaults.