Require Zeitwerk 2.6.1

[gmcgibbon]

What are you trying to accomplish?

Followup on #251.

Require Zeitwerk 2.6.1 so that we can always use the public introspection API to get application autoload paths.

What approach did you choose and why?

The loader approach previously used was good, but if we can just require a later version of Zeitwerk, we don't need to write branching logic for each version.

What should reviewers focus on?

Is there any reason not to impose a minimum version of Zeitwerk for the gem?

Type of Change

• Bugfix
• New feature
• Non-breaking change (a change that doesn't alter functionality - i.e., code refactor, configs, etc.)

Additional Release Notes

• Breaking change (fix or feature that would cause existing functionality to change)

Include any notes here to include in the release description. For example, if you selected "breaking change" above, leave notes on how users can transition to this version.

If no additional notes are necessary, delete this section or leave it unchanged.

Checklist

• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• It is safe to rollback this change.

[alexevanczuk]

This seems fine but would we call this a breaking change? We're removing support for <2.6.4, so I thought this could be released in the major version.

[rafaelfranca]

Not a breaking change since upgrading to Zeitwerk 2.6.4 should not break any app.

[rafaelfranca]

Suggested change

	Rails.autoloaders.inject({}) do |h, autoloader|
	Rails.autoloaders.inject({}) do |h, loader|

[rafaelfranca]

Suggested change

	h.merge(autoloader.dirs(namespaces: true))
	h.merge(loader.dirs(namespaces: true))

[rafaelfranca]

Loader is more correct here since those loaders can autoload or eagerload.

[gmcgibbon]

I wonder why Rails uses autoloaders naming then. 🤔 Will update!

[gmcgibbon]

This seems fine but would we call this a breaking change? We're removing support for <2.6.4, so I thought this could be released in the major version.

I wasn't 100% sure if adding version constraints is a breaking change, that's why I suggested the conditional logic in the original PR. However, I think Rafael is correct, bundler should be able to decide if an app can meet the version constraint or not.

Rails' constraint is "zeitwerk", "~> 2.5" as of 7.0, and that's on railties which we don't depend on in the gemspec. So, we should be specifying a zeitwerk dependency regardless if we ever want to support non-rails usage of Packwerk (and since we depend so heavily on it). Additionally, we reference Rails.root but don't depend on railties, so there's a few things still potentially wrong here. For now, I think adding the constraint for Zeitwerk makes the most sense to fix the bug we encountered.