Module: Kernel
- Defined in:
- lib/zeitwerk/kernel.rb
Class Method Summary collapse
- .require(path) ⇒ Object
-
.zeitwerk_original_require ⇒ Object
Zeitwerk’s main idea is to define autoloads for project constants, and then intercept them when triggered in this thin ‘Kernel#require` wrapper.
Class Method Details
.require(path) ⇒ Object
23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 |
# File 'lib/zeitwerk/kernel.rb', line 23 def require(path) if loader = Zeitwerk::Registry.loader_for(path) if path.end_with?(".rb") required = zeitwerk_original_require(path) loader.__on_file_autoloaded(path) if required required else loader.__on_dir_autoloaded(path) true end else required = zeitwerk_original_require(path) if required abspath = $LOADED_FEATURES.last if loader = Zeitwerk::Registry.loader_for(abspath) loader.__on_file_autoloaded(abspath) end end required end end |
.zeitwerk_original_require ⇒ Object
Zeitwerk’s main idea is to define autoloads for project constants, and then intercept them when triggered in this thin ‘Kernel#require` wrapper.
That allows us to complete the circle, invoke callbacks, autovivify modules, define autoloads for just autoloaded namespaces, update internal state, etc.
On the other hand, if you publish a new version of a gem that is now managed by Zeitwerk, client code can reference directly your classes and modules and should not require anything. But if someone has legacy require calls around, they will work as expected, and in a compatible way. This feature is by now EXPERIMENTAL and UNDOCUMENTED.
17 |
# File 'lib/zeitwerk/kernel.rb', line 17 alias_method :zeitwerk_original_require, :require |