If both Community and Freenode are enabled, Community settings seem to be ignored.

[djerius]

Perl 5.34, Perl::Critic::Community v1.0.2, Perl::Critic 1.140

If both Community and Freenode are enabled, Community settings seem to be ignored.

(As background, I don't use themes. I run against everything which I've installed, unless I explicitly exclude it. It's not currently documented in the top-level Community documentation that the same policies are also installed under the Freenode name. This caused me a bit of confusion during my debugging, as I was seeing Freenode policies and had never explicitly installed them.)

The following concocted code and perlcritic configuration illustrate the issue.

test code:

package Test;
use List::Util;
our $VERSION = 0.01;
1;

perlcritic.rc

verbose = 9
severity = brutal

exclude = TestingAndDebugging

[Community::StrictWarnings]
extra_importers = List::Util

I expect this to pass Community::StrictWarnings, but perlcritic returns:
[Community::StrictWarnings] Missing strict or warnings at line 1, near 'package Test;'. (Severity: 4)

I discovered that if I either

1. explicitly exclude Freenode; or
2. duplicate the settings under the Freenode::StrictWarnings namespace,

then the tests pass. It's not clear to me if the Freenode shims are just being reported as Community in the output or that they are actually hijacking Community's settings. Regardless, something is awry.

Thanks,
Diab

[Grinnz]

It's recommended to configure usage of the community theme explicitly such as shown in the main module documentation; if you run all policies, there will be duplicates with core policies as well.

As for the reported problem, I would guess that it is a mis-reporting of the policy name due to subclassing.

[djerius]

It's recommended to configure usage of the community theme explicitly such as shown in the main module documentation; if you run all policies, there will be duplicates with core policies as well.

Understood. There's definitely overlap between various themes/bundles (at least three Strict/Warnings policies that I've found). I appreciate the concept of curated sets of policies, but I've found it cognitively easier to throw everything into the mix and exclude those that I disagree with, are problematic, or are redundant, on an ad-hoc basis.

As for the reported problem, I would guess that it is a mis-reporting of the policy name due to subclassing.

A Perl::Critic issue perhaps? Shall I refile with that module?

[Grinnz]

Perhaps, see if it occurs in a minimal reproduction case of specifically using the freenode theme policy.