I wonder if this was supposed to be Array() with parens. That was a constructor at one point (perhaps still is) and would avoid another allocation (I think).

I had similar thoughts too but didn't want to play around with this particular line in this PR (only do cosmetic changes in lib/**/* in this PR; Handle specific optimizations in future PRs).

Your points are spot-on regarding allocations. Specifically, current implementation allocates 2 arrays at minimum:

• The outer [] allocates a new array irrespective of site.config["whitelist"] already being an array.
• The Array#flatten duplicates existing array, allocating another array just to handle site.config["whitelist"] already being an array.
• Now, there's a sticky situation here. Array(whitelist_config) alone won't ensure a flat list of strings. So, we have to call Array#flatten (or Array#flatten! with extra steps).

All of the decision overhead in the third-point is outside the scope of this PR.

Is this just too big a diff or do you find this one confusing so that's why it's disabled?

Current:

refute @collection.write?

After style change:

refute_predicate @collection, :write?

Doesn't the current seem clearer and easier to comprehend faster?
Maybe this is just a subjective preference. I'll go with whatever you decide (and apply same for the assert_predicate counterpart.)

Replied above, I think assert/refute predicate, message would be the best of both worlds, but no worries if there's not a cop for enforcing a message in assert/refute calls.

What's the reason for disabling this one?

Current:

assert before_time <= @site.time

After style change (with AssertOperator counterpart):

assert_operator before_time, :<=, @site.time

The new style is objectively harder for humans to parse. So, disabled without veto. (applied to counterpart RefuteOperator as well).

I see. I think the idea is to have better error messages since assert boolean_expr makes test output pretty useless. Perhaps we should enforce that assert calls must have a message component, i.e. assert boolean_expr, message_explaining_expectation. If it's not already a cop, then no worries.

Could we do EnforcedStyle: lf to use line feed everywhere? Maybe in a separate PR?

We could use EnforcedStyle: lf in the current PR as well without affecting CI or including more file changes. All files are already checked out by git with native line-endings automatically.

But for contributors-from-Windows' sake, we may perhaps need to reconfigure .gitattributes file.

Ok, I think we'd prefer to check in LF instead of CRLF. Can .gitattributes give us a per-repo way of saying "Windows needs CRLF so write them to disk but Git should remove the CR"? As a Windows user (or one in the past), I think you have the best understanding of how this should work.

Can .gitattributes give us a per-repo way of saying "Windows needs CRLF so write them to disk but Git should remove the CR"?

Yes. The jekyll/jekyll repo has that configured already.

Additional Reference: Example from GitHub Docs

I wonder if this could be a good cleanup in the future? Not sure the value of add_development_dependency anymore in a gemspec.

I was always in favor of moving dev-deps to Gemfile until I saw your commit @ rubocop-jekyll

I see -- I think it was more that I was too lazy to move them all to the Gemfile. I think managing dev dependencies in the Gemfile in 2024 makes sense, but no need to enforce it now if it's going to be a good amount of work (especially across repos).

I see -- I think it was more that I was too lazy to move them all to the Gemfile. I think managing dev dependencies in the Gemfile in 2024 makes sense, but no need to enforce it now if it's going to be a good amount of work (especially across repos).

Ok, I think we'd prefer to check in LF instead of CRLF. Can .gitattributes give us a per-repo way of saying "Windows needs CRLF so write them to disk but Git should remove the CR"? As a Windows user (or one in the past), I think you have the best understanding of how this should work.

I see. I think the idea is to have better error messages since assert boolean_expr makes test output pretty useless. Perhaps we should enforce that assert calls must have a message component, i.e. assert boolean_expr, message_explaining_expectation. If it's not already a cop, then no worries.

Replied above, I think assert/refute predicate, message would be the best of both worlds, but no worries if there's not a cop for enforcing a message in assert/refute calls.