Where is the best place to place the initialization files of third-party libraries in the slim framework or other microframeworks?

Question

Slim Framework

In general, a question of a theoretical nature, from the series "there are a lot of solutions, which is the best."
I invite unemployed people to the dialogue.
Essence. I use the slim framework , there is no built-in validation, I thought about using some kind of library. Outwardly, I liked the well-known vlucas / valitron
library. I got to the point of custom rules, I decided to make a rule for myself that checks if the email was sent for registration unique.
The implementation of custom rules is as follows:

Valitron\Validator::addRule('alwaysFail', function($field, $value, array $params, array $fields) {
    return false;
}, 'Everything you do is wrong. You fail.');

In other words, statics is called, the rule is added to the static array on the fly and it can be used.
Now about the main
thing I have been wondering for a long time - where and how in the structure of microframeworks it is necessary to set such initialization blocks of code? The main zapara - after all, all this initialization must be called before any checks, which means somewhere "above" in the code tree.
What options do I have:
1) Throw into the index.php file, but it feels like some kind of trash.
2) Use middleware
3) Maybe some service initialization file? But then how to turn them on if there are a dozen such libraries? Obviously, the coolest way for today -composer , but it does autoload files on request (if the code is used from there), or am I mistaken? Maybe there is some setting that allows you to specify composer'u initialization files?
And one more thing - do I understand correctly that such a structure as this validator has is not entirely correct?
Still, the option with creating classes for each rule somehow looks more familiar, or am I mistaken? ..
Thank you!

Answer 1

Xs as it is in slim, but in laravel there is a boot method in service providers, which is called after registering all the framework dependencies and before any trace. ongoing actions (such as processing a console command or an http request). Everything is usually registered there - it's ok.
Look for a slim lifecycle-like "hook".