Framework Bootstrap

Here's a short summary of what booting Tempest looks like.

• Tempest boots using the \Tempest\Framework\Application\Kernel class, the first step is to build the container
• Then there are bootstrap classes, each with an individual task. You find them in \Tempest\Framework\Application\Bootstraps
• Two bootstraps (DiscoveryLocationBootstrap and DiscoveryBootstrap) are tasked with setting up and executing discovery, which is the mechanism that will scan the whole codebase, and automatically register classes, you can read about it in the next chapter.
• The other bootstrap (ConfigBootstrap) is used for loading config. For now, loading config happens independent of discovery, but we plan on refactoring that.
• When bootstrapping is completed, the kernel return a fully configured container, which can be used to boot an application.

Applications#

Tempest provides two applications: ConsoleApplication and HttpApplication. Their name already suggests the difference between the two. Here's how to boot an application:

• As soon you've got a configured container object from the kernel, you can resolve a specific application from it: $application = $container->get(ConsoleApplication::class).
• You can provide additional application-specific configuration and setup if needed.
• Finally, you can call $application->run() to run it.

Because kernel bootstrap and application boot are two low-level framework concerns, Tempest offers a class that handles all these steps for you behind the scenes: \Tempest\Framework\Tempest.

This is the only line framework users should write to actually boot and run Tempest:

// For console applications:
Tempest::boot(getcwd())->console()->run();

// For HTTP applications:
Tempest::boot(__DIR__ . '/../')->http()->run();

Loading config#

• ConfigBootstrap will scan all registered discovery locations, and search for a folder called Config/ within each location. All files with .php will be registered as config files
• Discovery locations are determined based on composer. For example, your project root namespace is a discovery location (most likely called app or src). Another example is the Tempest vendor code itself, living in vendor/tempest. For now, it's sufficient to know that Tempest will detect all project code for you based on composer, and scan everything that's contains tempest code.
• Whenever config files are detected, they are registered as singletons in the container. That means that every config file is available to be injected in any class.

A config file would look something like this:

// app/Config/database.php

<?php

use Tempest\Database\DatabaseConfig;
use Tempest\Database\Drivers\SQLiteDriver;

return new DatabaseConfig(
    driver: new SQLiteDriver(
        path: __DIR__ . '/../database.sqlite',
    ),
);

Note that project-level config files are optional, Tempest loads default implementations if there's no user-specific config file. These default config files are located in src/Tempest/Framework/Config/. Whenever you create a new config class on the framework level, you should also add a corresponding config file for it in this location.