Code Generator Laravel Package

Getting Started

This is a Symfony 2–era, low-level scaffolding library — not a bundle. It gives you a CodeGenerator that renders stub templates with placeholder substitution and writes the rendered output to disk. There is no service to autoload from a bundle; you instantiate it directly.

Install (composer, PHP 5.3/5.4 constraints inherited from the Symfony 2 era):

composer require publero/code-generator:dev-master

If packagist resolution fails (it is a 0-star, 0-dependant package), clone the repo and add a path/vcs repository entry in your root composer.json:

"repositories": [{ "type": "vcs", "url": "https://github.com/Publero/symfony-code-generator-component" }]

Where to look first.

1. src/ — find the primary generator class (typically CodeGenerator or Generator). That class is the whole API.
2. Look for a Template/Token/Parser class — this is where placeholder syntax is defined (usually {{ token }} or %token%).
3. Look at tests/ — for a package this size the tests are the only reliable documentation of the placeholder grammar and the file-path conventions.
4. Look at composer.json — confirm the symfony/* constraints before pulling it into anything modern.

First use case — generate a class from a stub:

use Publero\Component\CodeGenerator\CodeGenerator;

$generator = new CodeGenerator('path/to/templates');
$generator->generate('Entity.php.twig', 'src/Acme/AppBundle/Entity/User.php', [
    'namespace' => 'Acme\\AppBundle\\Entity',
    'class'     => 'User',
    'fields'    => $fields,
]);

Treat that snippet as the shape, not Gospel — confirm the constructor signature and method name against src/ before wiring it in. The essential contract is: template in, tokens in, file on disk out.

The realistic first win is wrapping it in a small Symfony console command so you stop hand-writing boilerplate CRUD/entity/DTO classes.

Implementation Patterns

Stub + token map. Keep every .php stub outside src/ (e.g. app/Resources/code-generator/) so it is not autoloaded or scanned by static analysis. Render by passing an associative array of tokens; each key maps to a string the template substitutes verbatim. Because substitution is string-based, pass pre-escaped PHP ('Acme\\\\Entity' not 'Acme\Entity') and pre-formatted code blocks for anything variable-length.

One generator, many templates. The generator is stateless per invocation. Reuse a single instance:

$gen = new CodeGenerator($templatesDir);
$gen->generate('Entity.php.stub', $entityPath, $entityTokens);
$gen->generate('Repository.php.stub', $repoPath, $repoTokens);
$gen->generate('Controller.php.stub', $ctrlPath, $ctrlTokens + ['entity' => $entityClass]);

Compute the token array once per "artifact" (entity name, namespace, route prefix, table name) and fan it out across all templates. This is the pattern that makes the package worth using: a single command scaffolds an entire vertical slice.

File paths as templates too. Any half-decent code generator of this vintage supports placeholders in the destination path. Use that to encode the Symfony convention instead of hardcoding paths:

$gen->generate('Entity.php.stub', "src/{{ bundle }}/Entity/{{ class }}.php", $tokens);

This keeps the generator agnostic of your bundle layout — swap the destination template per project.

Wrap it as a console command, not a controller. The generator does file_put_contents/Filesystem writes; you do not want HTTP requests dropping files on your server. A app/console acme:generate:crud AcmeBlogBundle Post command is the correct integration point. Inject the generator via the container and pass --force as an explicit option.

Composition over inheritance. If you need per-artifact validation (e.g. "class name must be StudlyCase"), do it in the command before calling the generator. The package almost certainly has no validation layer, and subclassing an abandoned Symfony 2 class is a maintenance trap.

Integration with SensioGeneratorBundle. If you are on Symfony 2.3–2.8 and already have SensioGeneratorBundle, use this package for the generic "render stub → write file" mechanics and keep the interactive question/answer flow in Sensio's GeneratorCommand. Do not try to replace Sensio wholesale; this component is a rendering primitive, not a full generator framework.

Token preprocessing for collections. For repeated blocks (Doctrine fields, route stanzas, getter/setter pairs), do not try to teach the template engine to loop — the engine will not support it. Render the repeated block yourself into a single string with implode("\n") in PHP, then inject it as one token:

$tokens['fields'] = implode("\n", array_map(
    fn($f) => "    /** @ORM\\Column(type=\"{$f['type']}\") */\n    protected \${$f['name']};",
    $fields
));

This is the standard workaround for every simple placeholder-substitution generator and it is what you will end up doing here.

Gotchas and Tips

The package is abandoned and effectively undocumented. With 0 stars and 0 dependents, there is no Stack Overflow trail, no changelog you can trust, and no maintainer to answer an issue. Budget an hour to read src/ end-to-end before depending on it. If the API surface turns out to be more than ~3 classes, consider copying the source into your app under your own namespace rather than pulling it in as a dependency — that way you own the bug fixes.

Symfony 2 constraints will bite on modern stacks. Check composer.json for symfony/console, symfony/filesystem, and symfony/finder version pins. This component predates Symfony 3's BC breaks and Symfony 4's Flex-based structure entirely. On Symfony 3+/4+ you will likely get Your requirements could not be resolved to an installable set of packages. The class code itself is usually portable — the composer metadata is the blocker.

PHP version floor. Expect php: >=5.3.3 in constraints and, potentially, short-array-free or array()-heavy source. If you are on PHP 8.x and the package uses each(), create_function(), or unquoted string-keyed array access, expect deprecation/fatal issues. Grep the source for these before install.

No overwrite protection by default. Most generators in this lineage write unconditionally, silently clobbering hand-edited files. Always guard the call:

if (file_exists($target) && !$input->getOption('force')) {
    throw new \RuntimeException("Refusing to overwrite {$target}; pass --force");
}

Add this check in your command wrapper — you cannot rely on the component to do it.

Placeholder delimiter collisions. The delimiter is whatever the Template/Parser class hardcodes. If it is {{ }} you will collide with Twig if you ever route stubs through Twig; if it is %name% you will collide with Symfony's parameter syntax. Never store stubs as .twig files served by the templating engine. Confirm the delimiter in the parser class and document it in a comment at the top of every stub.

Escape backslashes and $. Substituted values are inserted raw. A namespace token of Acme\AppBundle\Entity will mangle the output if the parser treats backslashes as escapes; a token value containing $variable may be re-expanded if you ever swap the renderer for sprintf or preg_replace with /e. Test with a token value containing \, $, and { before relying on it.

Destination directory creation is often missing. Verify whether the generator mkdir -ps the parent directory of the target file. If not, wrap the call yourself with Filesystem::mkdir() — otherwise you will get a bare file_put_contents(): failed to open stream with no context.

Debugging rendering. Do not debug against the destination file. Render to a string/php://temp first and var_dump the result, or generate into a var/tmp-gen/ scratch directory and diff against expected output. A diff against a known-good generated file is the fastest way to diagnose a wrong token map.

Extension point is thin, and that is fine. The one genuinely useful extension hook is the template loader — if the class accepts a loader/renderer in its constructor, you can swap in a Twig-backed renderer to gain loops and conditionals while keeping the generator's file-writing behavior. If it does not, subclass the generator and override the render method, but keep the override to a single method.

License is MIT, source is short. If you decide the dependency is too risky, MIT means you can vendor the two or three relevant classes directly into app/CodeGenerator/ with attribution and drop composer. For a package this small and this stale, that is often the correct engineering call.