Drupal Code Generator Laravel Package

Getting Started

DCG is the engine behind drush generate, so the fastest path is usually Drush already installed in your project. For standalone use (or a newer version than Drush bundles):

composer require --dev chi-teck/drupal-code-generator
vendor/bin/dcg list            # every available generator, grouped
vendor/bin/dcg module          # interactive scaffold

Run it from the Drupal project root so it can detect the Drupal version and place files under modules/custom, themes/custom, etc.

First use case: scaffold a custom module, then generate a block plugin inside it rather than hand-writing boilerplate.

drush generate module            # or: vendor/bin/dcg module
drush generate plugin:block      # answers: module name, plugin ID, class

Where to look first: the list output (it exposes the generator namespace, e.g. plugin:field:formatter, entity:content, test:kernel), then the prompt flow itself — each generator asks exactly what it needs. Keep the repo README open for the "custom generators" section if your team standardises on house style.

Implementation Patterns

Interactive day-to-day. Use drush generate <generator> as the default. It is the same code path as dcg, but runs in site context and is already wired into your toolchain. Typical cadence: module → plugin:* / service / form:simple / controller → yml:services / yml:routing / yml:permissions → test:kernel / test:functional. Using the YAML generators keeps indentation and key ordering consistent across the team.

Scripted / repeatable scaffolding. Pass answers as flags to skip the UI — useful in onboarding scripts, CI fixtures, or when generating many similar plugins:

vendor/bin/dcg module \
  --destination=modules/custom \
  --answer name=acme_blocks \
  --answer description="Shared block plugins"

The --answer keys mirror the prompt names; run the generator once interactively to learn them. --destination lets you emit into a scratch directory for inspection before moving files.

Compose generators, don't hand-roll. Generate the module first, then generate into its machine name. For content entities use entity:content then follow with plugin:field:* and migration scaffolds; for themes generate theme then css/javascript/library files rather than creating them by hand.

Custom generators for agency standards. Extend the base generator classes, register them on a custom Symfony\Component\Console\Application that bootstraps DCG, and ship that as a small internal package or binary. This is the right lever when every project needs the same module skeleton, CI config, or plugin naming conventions.

Drush vs standalone. Prefer drush generate when Drush is present (site context, Drupal version detection, consistent version with the rest of the project). Use vendor/bin/dcg in non-Drupal repos, in CI, or when you need behaviour not yet in Drush's pinned dependency.

Gotchas and Tips

• Version drift. Drush pins a DCG version. Installing the package locally can shadow or conflict with it. Check composer show chi-teck/drupal-code-generator and drush generate --version before assuming a missing generator is a bug — it may just be an older release.
• PHP constraints. Recent releases require modern PHP; on older runtimes Composer resolves an older DCG with fewer generators. If a generator you expect is absent, check the resolved version first.
• Run inside the project root. Outside it, Drupal version detection and default destinations fall back to prompts/CWD-relative paths. Be explicit with --destination if you're generating elsewhere.
• Generated code is a starting point. The scaffolds produce correct skeletons, but wiring (service definitions, library attachments, schema, permissions) frequently still needs manual edits. Treat output as a reviewed diff, not a finished feature.
• Clean working tree first. Some generators will overwrite existing files; running with a clean tree lets git diff show exactly what changed and makes rollback trivial. Test unfamiliar generators into a scratch --destination first.
• Pick names up front. Machine names are validated (lowercase, underscores) and are baked through class names, file names, and YAML keys. Renaming afterwards means a project-wide find/replace.
• Answer keys are per-generator. There is no universal --answer name=... schema; inspect the prompts or --help for the generator in question. Typos silently pass through as literal strings.
• Extension point. Custom generators must be registered on the console application — the stock binary has no hot-reload of a generators directory. Keep your custom application in its own package so the registration is versioned with the generators.
• Debugging. Use -vvv for verbose Symfony output when a generator fails; reproduce in a scratch directory to isolate path/permission issues from template errors.