Prefer Pathname#glob to Dir.[] at spec/rails_helper.rb template

[r7kamura]

Since Pathname#glob was added in Ruby 2.5, I thought it would be more concise to use this on spec/rails_helper.rb template.

Unlike Dir.[], Pathname#glob returns an array of Pathname, but Kernel.#require works the same way if you give an Pathname as an argument, so I think there should be no problem about this difference here. We could add .map(&:to_s), but I think that would be a bit redundant.

[JonRowe]

Thanks for the suggestion, merged because I can't see why not.

[JonRowe]

Released in 6.1.0

[franzliedke]

We could add .map(&:to_s), but I think that would be a bit redundant.

It turns out this affects sorting.

• For pathnames, spec/support/dir/a.rb comes before spec/support/dir.rb
• For strings, spec/support/dir.rb comes first

Not sure if we just do weird things in our support scripts (dir/a.rb relying on constants from dir.rb). This came up because Rubocop started preferring the Pathname#glob version as well. 😬

[pirj]

Wondering what RuboCop guys would say about this. I’d expect the order to remain the same as it was with Dir.[], and dir.rb to come first. The latter seems to do with the Pathname itself. Wondering if this is the first time the combination of that cop with order-dependency bites someone?

[franzliedke]

@pirj The ordering as returned by Dir.[] and Pathname#glob is the same for both (at least on my Linux system, and Ruby 3+), but that's apparently not true for Pathname#<=> and String#<=>.

[JonRowe]

We could change sort to sort_by(&:to_s) here to solve this, or just drop back to the Dir style, would you like to work up a PR with either?

[pirj]

not true for Pathname#<=> and String#<=>.

That’s what I meant. But indeed the cop is not directly responsible due to us calling sort on the results.
It is more a Pathname issue apparently. Is it worth reporting in the gem? https://github.com/ruby/pathname/issues

[franzliedke]

@JonRowe I'm happy to send a PR.

@pirj I think the fact that pathname.glob(...) has the same order of pathname.glob(...).sort is a strong argument that their <=> implementation is "correct", even though it makes use cases like this one (requiring an entire tree of files in a semantically sensible order) harder.

Random idea: We could check out how Zeitwerk determines the order when eager loading a directory.

[pirj]

https://github.com/ruby/pathname/blob/9d0190017f1ade0850bb6c47d8cf0c4165ea1dc0/test/pathname/test_pathname.rb#L540 is not too verbose. Can we call the behaviour in our case undetermined?

has the same order

What if it just returned the same reverse ordered list like z, y, x?