Prefer require_relative for internal requires

[tagliala]

require_relative is preferred over require for files within the same project because it uses paths relative to the current file, making code more portable and less dependent on the load path.

This change updates internal requires to use require_relative for consistency, performance, and improved portability.

Retain require for dynamic paths in lib/haml_lint.rb because they use absolute paths.

Refs:

• Prefer require_relative rubocop/rubocop#8748

---

Hello, this should also provide a minor performance improvement in loading time because require_relative is O(1), but please confirm my findings

./bin/haml-lint --version (with changes to prefer the current library) appears to be 7%/4.5% faster on M1 Pro, according to Ruby version and architecture

# 3.3.5 x64    `real` (avg of several runs)
`main`:        0m1.625s
`this branch`: 0m1.546s

# 3.3.3 arm64  `real` (avg of several runs)
`main`:        0m0.933s
`this branch`: 0m0.883s

---

If this is going to be accepted, I'll do the same for slim-lint

[sds]

Supportive, just confused about the term "relative" here.

[sds]

Why would this not be ./constants? (Just curious)

[tagliala]

Hi,

no because haml_lint is in lib, and constants is in lib/haml_lint/constants.rb, so the relative path does include haml_lint

lib/
├── haml_lint/
│   └── constants.rb
└── haml_lint.rb

This is a good reference in a (former) ruby core gem: https://github.com/ruby/logger/blob/d1d704a6336a82903011336a0116012e9aa4a504/lib/logger.rb#L17-L21

[tagliala]

Some other reference in Ruby core that are not linked in this PR:

• Prefer require_relative for internal requires ruby/psych#522
• Prefer require_relative ruby/rdoc#658

[sds]

Reading from the GitHub app on my phone was throwing me off. Pathing makes sense 👍

[sds]

Thanks. Reads odd to me for a "relative" path to not include a leading ./, but no objections otherwise.

[tagliala]

Thanks, I'm going to do the same for slim_lint

[MaxLap]

Thanks. Reads odd to me for a "relative" path to not include a leading ./, but no objections otherwise.

In case it helps, the way I see it, in general, every path is "relative" unless it starts with a /. The question is relative to what. If it starts with ./, it's relative to current directory (current being unusual in the contect, ~/ is relative home directory and otherwise its relative to some chosen default.

In the case of requires within a gem, what is nearly always desired is relative to the current file (requirrelative to gem's root could make sense too, but that would be extra work to figure out with little benefit) . This is what require_relative does. It is better than using require with a special path because its less error prone and can be faster by not having to do extra processing on the string.

[tagliala]

Can you confirm any actual speed-up?

I'm having mixed results, it appears to be no differences between the two versions in a third-party application after a few runs

[sds]

From the rubocop thread you linked it sounds like this potentially has more of an impact on Windows machines?

But perhaps there's a reason that issue was never closed.

[tagliala]

I've tested the released gems also on windows and unfortunately, at least on my environment, there are no performance differences

require "haml_lint"

haml-lint 0.58.0
Average: 2.0339336999997615

haml-lint 0.59.0
Average: 2.029540899999847

bundle exec haml-lint --version

haml-lint 0.58.0
Average: 2.8111768999995546

haml-lint 0.59.0
Average: 2.805723960000614

haml-lint --version

haml-lint 0.58.0
Average: 2.2467118700020365

haml-lint 0.59.0
Average: 2.2358569299976807

In any case, performance would have been only a nice side effect, there are other reasons to switch to require_relative:

• Benchmarks: are memowise results reliable? panorama-ed/memo_wise#349 (comment)
• Prefer require_relative for internal requires ruby/psych#522

[sds]

Thank you for performing the benchmarks. Agree even if there's no significant difference it's still worth keeping the use of require_relative.