Magento Module Boilerplate Generators in Daily Development

1. Why boilerplate generators raise module quality

A new Magento module needs at least registration.php, module.xml, a vendor namespace, and usually a first class with correct PHPDoc right from the start. Anyone typing this out by hand every time sooner or later makes small mistakes: a forgotten setup_version, a mismatched module name versus folder name, a missing dependency declaration. A boilerplate generator eliminates this entire class of errors, because the structure always comes from the same, verified template.

The second benefit of a boilerplate generator is consistency across the whole team. If every developer brings their own idea of folder structure, namespace convention and PHPDoc verbosity, an inconsistent codebase emerges over time. A centrally maintained generator implicitly forces everyone onto the same conventions, without needing to consult a style guide document every time.

This article walks through the different tiers of boilerplate generators for Magento 2 modules: from the official CLI tool through custom Composer templates to PhpStorm Live Templates for individual classes like repositories and plugins.

2. registration.php and module.xml: the minimal boilerplate

Before a generator can be meaningfully evaluated, it needs to be clear what the minimal, correct boilerplate for a Magento module actually contains. registration.php registers the module name and path via ComponentRegistrar::register(), while module.xml declares the setup_version and dependencies on other modules. Both files must match exactly, otherwise bin/magento module:enable fails with a hard-to-read error message.

A common beginner mistake when building this manually: the module name in registration.php diverges from the name in module.xml, because a spot was overlooked while copying an existing file. A boilerplate generator that derives both files from a single input, vendor and module name, structurally cannot produce this discrepancy in the first place.

<?php
// app/code/Vendor/Module/registration.php
// Minimal boilerplate — must match module.xml exactly
declare(strict_types=1);

use Magento\Framework\Component\ComponentRegistrar;

ComponentRegistrar::register(
    ComponentRegistrar::MODULE,
    'Vendor_Module',
    __DIR__
);

3. create-magento-module and command-line generators

The community tool create-magento-module (package magento-hackathon/magento2-module-generator or newer variants) generates exactly this minimal boilerplate from the command line in seconds, including a correct directory tree for etc, Model and Setup. For a team that regularly creates new modules, this single command already saves several minutes per module compared to manual creation, and eliminates the typical typos in module names.

Important for productive use: the generated skeleton should always be reviewed manually once more, especially the generated composer.json, since not every boilerplate generator automatically sets the correct PHP version constraints or Magento dependencies for the current project. A generator is a starting point, not a black box to be blindly adopted.

#!/usr/bin/env bash
# Generate a new module skeleton with create-magento-module
set -euo pipefail

bin/composer require --dev magento-hackathon/magento2-module-generator

bin/cli createMagentoModule \
  Vendor Module \
  --add-blocks \
  --add-helpers \
  --add-model \
  --module-dir=app/code

# Always review the generated composer.json and module.xml manually
cat app/code/Vendor/Module/etc/module.xml

4. Custom skeleton generators with Composer templates

Generic tools cover the standard case, but every team has its own conventions: a fixed PHPDoc template, mandatory ViewModel structure instead of block classes, a standard system.xml skeleton for configuration. A custom boilerplate generator, built with composer create-project and a dedicated skeleton repository, codifies exactly these team conventions and is often more valuable in the long run than a generic community tool.

The setup is manageable: a private Composer package with placeholders in file names and content, such as __VENDOR__ and __MODULE__, that get replaced with actual values via script after copying. This approach lets you bake a complete ViewModel, a repository interface and the required system.xml structure directly into the skeleton, instead of adding them by hand for every new module.

{
  "name": "mironsoft/module-skeleton-template",
  "description": "Internal boilerplate generator template for new Magento modules",
  "type": "magento2-module",
  "require": {
    "php": "~8.4.0"
  },
  "extra": {
    "skeleton-placeholders": {
      "__VENDOR__": "Vendor name, PascalCase",
      "__MODULE__": "Module name, PascalCase",
      "__VENDOR_LOWER__": "Vendor name, lowercase for config paths"
    },
    "skeleton-includes": [
      "etc/module.xml",
      "etc/di.xml",
      "etc/adminhtml/system.xml",
      "etc/adminhtml/acl.xml",
      "ViewModel/__MODULE__ViewModel.php",
      "registration.php"
    ]
  }
}

5. PhpStorm Live Templates for Magento boilerplate

While Composer-based generators produce entire modules, PhpStorm Live Templates are the right tool for recurring boilerplate building blocks within an existing module: a new plugin class, a repository interface, a data patch. A live template with variables for class name and namespace produces a complete PHPDoc skeleton in seconds according to project standards, including constructor property promotion and typed parameters.

The advantage over an external boilerplate generator: live templates work directly in the editor, without a context switch to the command line, and can be exported and shared across the whole team. For Magento teams, a shared live template set for the most common building blocks, plugin, observer, repository, data patch, is worthwhile, versioned as a file in the project repository and imported as needed.

6. Automated interface and repository generation

Repository pattern implementations in Magento follow a very repetitive pattern: an interface with CRUD methods, a concrete implementation, a search result interface and the associated di.xml wiring. This exact repetition makes repositories the ideal candidate for a focused boilerplate generator that automatically produces all four files consistently from an entity name.

A self-built PHP script that fills a template with placeholders and adds the matching preference wiring to di.xml saves several manually error-prone steps for every new entity type. Important here: the generated code must still pass PHPStan and coding standard checks, a boilerplate generator does not replace quality assurance, it only reduces manual writing effort.

<?php
declare(strict_types=1);

namespace Vendor\Module\Api;

use Vendor\Module\Api\Data\__ENTITY__InterfaceFactory;

/**
 * Generated repository interface skeleton for __ENTITY__.
 * Replace __ENTITY__ with the actual entity name during generation.
 */
interface __ENTITY__RepositoryInterface
{
    /**
     * Loads an entity by its identifier.
     *
     * @param int $id Entity identifier
     * @return \Vendor\Module\Api\Data\__ENTITY__Interface
     * @throws \Magento\Framework\Exception\NoSuchEntityException
     */
    public function getById(int $id): \Vendor\Module\Api\Data\__ENTITY__Interface;

    /**
     * Persists an entity.
     *
     * @param \Vendor\Module\Api\Data\__ENTITY__Interface $entity Entity to save
     * @return \Vendor\Module\Api\Data\__ENTITY__Interface
     */
    public function save(\Vendor\Module\Api\Data\__ENTITY__Interface $entity): \Vendor\Module\Api\Data\__ENTITY__Interface;

    /**
     * Deletes an entity by its identifier.
     *
     * @param int $id Entity identifier
     * @return bool
     */
    public function deleteById(int $id): bool;
}

7. Boilerplate for tests: generating PHPUnit skeletons

An often overlooked use case for boilerplate generators is the test class itself. For every new repository or plugin class, a PHPUnit test class with the correct namespace, mock setup for constructor dependencies and at least one basic test case should ideally exist immediately. If this skeleton is rewritten manually for every class, the likelihood of a test being written at all drops noticeably.

A simple approach: a script that reads the target class's constructor signature via reflection and automatically produces the matching mock declarations in the generated test skeleton. This significantly lowers the entry barrier for test coverage, since the developer does not start from zero but only needs to add the actual test logic instead of typing mock boilerplate by hand.

#!/usr/bin/env bash
# generate-test-skeleton.sh — reflect a class and scaffold a matching PHPUnit test
set -euo pipefail

CLASS_FQN="$1"
TEST_DIR="Test/Unit"

bin/cli reflectionToTestSkeleton \
  --class="$CLASS_FQN" \
  --output-dir="$TEST_DIR" \
  --mock-constructor-args

echo "[OK] Test skeleton generated for $CLASS_FQN in $TEST_DIR"

8. Pitfalls: generators producing outdated patterns

Not every boilerplate generator keeps up with current Magento best practices. Older community tools still generate InstallSchema.php skeletons instead of declarative schema in some cases, or generate block classes as the default even though ViewModels have been the recommended approach for pure presentation logic since Magento 2.2. Adopting a generator without review imports outdated patterns directly into new modules.

That is why regularly reviewing the generator templates themselves belongs in a team's maintenance plan. A boilerplate generator that is set up once and never touched again drifts from current Magento recommendations over time. A simple check: generate a new test module every quarter and manually verify its code against the current PHPStan configuration and coding standard version.

9. Generator tools compared

The following table compares the different tiers of boilerplate generators for Magento 2 modules by effort and control.

Many teams combine several tiers: create-magento-module or a custom Composer template for the base structure, PhpStorm Live Templates for daily refinement of individual classes. This combination covers both the rare case, a whole new module, and the frequent case, a new class in an existing module, with matching boilerplate.

10. Summary

Boilerplate generators for Magento 2 modules solve two problems at once: they save time when creating new structure and they enforce consistency across the whole team. From the official CLI tool create-magento-module through custom Composer templates to PhpStorm Live Templates for individual classes, each tier covers a different use case, from a whole new module down to a single repository class.

The most important point when introducing a boilerplate generator is regular maintenance of the templates themselves. A generator producing outdated patterns like install scripts or block classes instead of ViewModels does more harm than good, because it automatically carries these patterns into every new module. Teams that treat generators as a living tool and regularly check them against current best practices gain noticeable development speed.

11. FAQ: Magento Module Boilerplate Generators