Introduce a boot.rb file

[sandstrom]

I'm having some trouble adding custom directories to the load path.

Specifically, I'd like to add lib/ to load path, because I have lib/utils/misc.rb that I want to load.

Maybe we should add a boot.rb file. It could be empty by default, or possibly call some simple setup function on Bridgetown (such as Bridgetown.begin! or a new Brigetown.setup!). That way, there would be a known place to stick stuff that should execute very early.

This is what Rails have in environment.rb (I don't like that filename though):

```ruby

# Initialize the Rails application.
Rails.application.initialize!

```

This could be a good place for e.g. making modifications to other gems early, for example this modification we did to I18n (we put it in a builder, but that's not really the right place). See #598 (comment)

I'm sure there are other users too. Basically a low-level hook, in the form of a user-controlled file (part of default file structure, checked into version control, but modifiable by the user).

[jaredcwhite]

@sandstrom I think the upcoming Initializers feature of 1.2 will fit the bill of what you're asking. https://edge.bridgetownrb.com/docs/configuration/initializers

And you're right, using a builder to customize a gem isn't ideal, but prior to initializers we didn't really have a good alternative.

[sandstrom]

Great stuff!

The initializers design may be finalized already (I know 1.2 is in beta), so this may be a bit late. Also, these things may have been considered already and discarded for good reason. All that said, here are some thoughts:

• Require-by-default feels "too magic" for me, I would at least have gone with an explicit require_gem: true for every init block. I'd probably even try to use regular require calls, for even more 'standard ruby' use.

• Was multiple initializer files considered?

  # EXAMPLE OF WHAT A FILE AT config/initializers/stripe.rb` COULD LOOK LIKE
  require 'stripe'
  
  Bridgetown.logger.info "Stripe:", "Setting the API key"
  Stripe.api_key = api_key

• You are probably well aware, but I know Rails had some issues around autoloading, Zeitwerk and initializers (https://guides.rubyonrails.org/v6.1.0/autoloading_and_reloading_constants.html#autoloading-when-the-application-boots, https://rubyonrails.org/2021/9/3/autoloading-in-rails-7-get-ready).

---

All of this said, the upcoming initializers are still going to be useful, even in it's current form! Just wanted to provide some feedback & thoughts.

[jaredcwhite]

@sandstrom Thanks for your feedback! There has been a fair bit of consideration already worked into this system, so for example you can indeed create multiple initializer files, but they work a bit differently than in your example. See: https://edge.bridgetownrb.com/docs/configuration/initializers#the-init-method-and-initializers

The reason require_gem is opt-out, rather than opt-in, is because the vast majority of init statements will be related to a gem/plugin. Perhaps some of the consternation is we're using the same term (initializers) as in Rails, but ours are rather different (and perhaps we should call out more explicitly that Bridgetown initializers do not work the same way as Rails initializers. TBH, I don't care much for the design of Rails initializers).

On the Zeitwerk/autoloading bit, we have hooks available which could be defined within the initializers, for example:

hook : loader, : post_reload do |loader, load_path|
  # do something after a reload
end

Hopefully that would handle similar concerns to the Rails examples.

[sandstrom]

@jaredcwhite Sounds like you've already thought these things through!

Looking forward to 1.2! 😄