Additional components

Next to the previously mentioned main components, some additional components exist. Those are mainly used while processing the various build steps.

Composer interaction

The Resource\Local\Composer component provides a way to install Composer dependencies, described by an existing composer.json file:

$installer = new \CPSIT\ProjectBuilder\Resource\Local\Composer();
$exitCode = $installer->install('/path/to/composer.json', output: $output);

Error handling

During bootstrapping, the Error\ErrorHandler component is initialized. It is responsible for handling exceptions that are thrown by the application. On verbose output, the exception is passed through the Composer application.

I/O handling

Additionally, there exist two core components that are responsible for I/O handling:

1. The IO\Messenger component takes care of every message that is passed to the user. Additionally, it provides some helper methods to interact with the user or provide a styled output for e.g. new sections or user selections.

2. While the Messenger mainly targets the application’s output behavior, a second component IO\InputReader handles user input. It’s mainly used when processing interactive build steps to fetch and apply user input. The InputReader depends on an active IO object, which is only available to the Messenger, thus it implicitly depends on it.

Example:

/** @var \CPSIT\ProjectBuilder\IO\InputReader $inputReader */

$phpVersion = $inputReader->choices('Which PHP version should be used?', ['8.1', '8.0']);
$name = $inputReader->staticValue('What\'s your name?');
$password = $inputReader->hiddenValue('What\'s your password?');

if ($inputReader->ask('Confirm project generation?', default: false)) {
    // Project generation confirmed, continue...
}

As an additional I/O component, some validators exist, ready to be used by the InputReader:

Type	Class	Description
callback	CallbackValidator	User input is validated by a given callback
email	EmailValidator	User input must be a valid e-mail address
notEmpty	NotEmptyValidator	User input must not be empty (strict mode available)
regex	RegexValidator	User input must match a given regular expression
url	UrlValidator	User input must be a valid URL

Each validator implements ValidatorInterface.

Note

Not all validators can be used for each interaction with the InputReader.

Naming

With the Naming\NameVariantBuilder component, it is possible to create variants of project and customer names. For this, the current build instructions are used. All available name variants are described in the Naming\NameVariant class.

Template rendering

Project templates must be written as Twig template files.

Each template file is rendered by the Twig\Renderer component. The Renderer internally heavily makes use of a custom Twig extension, the Twig\Extension\ProjectBuilderExtension component. Within this extension, a prebuilt set of Twig filters and functions is registered.

Twig filters

The following Twig filters currently exist:

Name	Class	Description
convert_case	ConvertCaseFilter	Convert string to a given string case
slugify	SlugifyFilter	Generate slug from given string by using cocur/slugify

Each Twig filter implements TwigFilterInterface.

Twig functions

The following Twig functions currently exist:

Name	Class	Description
is_default_project_name	DefaultProjectNameFunction	Check if given project name is the default project name as described by NameVariantBuilder::isDefaultProjectName()
get_default_author_email	DefaultAuthorEmailFunction	Read default author e-mail address from global Git config
get_default_author_name	DefaultAuthorNameFunction	Read default author name from global Git config
get_latest_stable_php_version	PhpVersionFunction	Fetch the latest stable PHP version from PHP REST API (response is cached)
name_variant	NameVariantFunction	Create name variant with NameVariantBuilder::createVariant()
resolve_ip	ResolveIpFunction	Resolve IP address for a given hostname or URL

Each Twig function implements TwigFunctionInterface.