PHPackages                             codger/generate - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Framework](/categories/framework)
4. /
5. codger/generate

ActiveLibrary[Framework](/categories/framework)

codger/generate
===============

Code generator, base framework

0.10.4(1y ago)0654[1 PRs](https://github.com/codger-php/generate/pulls)4MITPHPPHP >=8.1

Since Sep 8Pushed 1y ago1 watchersCompare

[ Source](https://github.com/codger-php/generate)[ Packagist](https://packagist.org/packages/codger/generate)[ RSS](/packages/codger-generate/feed)WikiDiscussions master Synced 3d ago

READMEChangelogDependencies (3)Versions (60)Used By (4)

codger/generate
===============

[](#codgergenerate)

CODe GEneratoR, base framework

In any software project adhering to some form of standards (be it your own or those "mandated" by a framework) there will be lots of boilerplate code. E.g. in an MVC setting you'll (pratically) always have models, views and controllers for each component that in their core are similar. An example would be if you use Doctrine - the entities are generated based upon your database schema directly.

Codger aims to offer code generation tools that take this principle a step further, allowing you to specify so-called *recipes* for artbitrary code generation.

Although Codger itself uses PHP and Twig, the generated code can theoretically be in any language. As an example, a recipe for Chef code is included.

Installation
------------

[](#installation)

```
$ composer require --dev codger/generate
```

> Typically you'll install a more specific package like `codger/php`, which has `codger/generate` as a dependency.

Usage
-----

[](#usage)

```
$ vendor/bin/codger name-of-recipe some additional arguments --or --options
```

The name of the recipe should be resolvable to a PHP class name. The rules for this are as follows:

- slashes or semicolons are converted to backslashes (namespace separator);
- characters following a hyphen are uppercased;
- other characters are lowercased, barring the first which is uppercased.

Additionally, all recipes are prefixed with the `Codger` namespace. This allows you to easily group them in a directory outside of your regular source code, e.g. a `./recipes` folder.

Thus, a recipe `monolyth:some-test` would resolve to the namespace `Codger\\Monolyth\\SomeTest`.

Default options
---------------

[](#default-options)

All Codger recipes support 2 default options as defined in the `Codger\Generate\DefaultOptions` trait:

- `--output-dir=/some/path`. Supply this to actually attempt to write generated files to disk; the default is to dump to screen for manual inspection.
- `--replace`. If this flag is set, existing files will be overwritten without warning (the default is to prompt for overwrite, dump or skip).

Whether or not shorthand flags exist depends on your recipe's other options.

Writing recipes
---------------

[](#writing-recipes)

All recipes are regular PHP classes extending `Codger\Generate\Recipe`. The main work should be done inside the `__invoke` method. Codger recipes extend the `Monolyth\Cliff\Command` class, so (string) parameters to invoke are treated as CLI operands. Hence, a recipe called `Codger\Foo` with an `__invoke` signature of `(string $name)` would be called as `vendor/bin/codger foo myname`.

As noted before, Composer should be able to autoload the recipes. E.g., add an `autoload-dev` property to your `composer.json` for something like `"Codger\\MyNamespace\\": "./recipes"`.

Inside the `__invoke` method, your recipe should do its stuff. What that is depends on what you want to happen, of course, but generally a recipe should at least call `output()` to specify what it is generating, or call `delegate` to specify it needs to delegate tasks to a sub-recipe.

```