Magento Coding Standard

To prevent build failures and missing test reports in the Magento 2 repository, do not import namespaces that start with Magento\Tests.

This issue often occurs when an IDE automatically imports a namespace for a return data type (like string or float) from a test utility instead of using the native type or the correct production namespace. Importing from Magento\Tests can cause static tests to fail without providing clear error reasons and can lead to missing build reports for 'Database Compare', 'Functional Tests', and 'Sample Data Tests'.

In PHTML templates, $this refers to the current block. Using $this is considered legacy (from Magento 1) and is discouraged to ensure templates and blocks remain decoupled.

To comply with the coding standard, always use $block instead of $this. If you are currently accessing private or protected methods via $this, you must refactor those methods to be public so they can be accessed via $block.

To use the Magento coding standards within an existing Magento 2 project, install the package as a development dependency using Composer.

Note: For security reasons, the standard is not added to PHP_CodeSniffer's installed paths automatically. You must manually configure your composer.json to register the paths during installation or updates.

composer require --dev magento/magento-coding-standard

Add this to your composer.json to automate path registration:

"scripts": {
    "post-install-cmd": [
      "([ $COMPOSER_DEV_MODE -eq 0 ] || vendor/bin/phpcs --config-set installed_paths ../../magento/magento-coding-standard/)
    ],
    "post-update-cmd": [
      "([ $COMPOSER_DEV_MODE -eq 0 ] || vendor/bin/phpcs --config-set installed_paths ../../magento/magento-coding-standard/)
    ]
}

If you encounter a warning regarding the use of $this in a PHTML file, refactor the code to use the $block variable.

Example Fix: If your code uses $this->someMethod(), change it to $block->someMethod(). Note that someMethod must be a public method on the block class.

The ForeachArrayMergeSniff rule identifies performance issues caused by calling array_merge() inside a foreach loop. Merging arrays repeatedly within a loop is resource-intensive, leading to high CPU usage and slow execution times because a new array is created and all elements are copied in every iteration.

To fix this, collect the arrays into a temporary collection during the loop and perform a single array_merge() using the spread operator (...) after the loop has finished.

// BAD: array_merge inside a loop
$options = [];
foreach ($configurationSources as $source) {
    // code here
    $options = array_merge($options, $source->getOptions());
}

// GOOD: Collect arrays and merge once after the loop
$options = [];
foreach ($configurationSources as $source) {
    // code here
    $options[] = $source->getOptions();
}

$options = array_merge([], ...$options);

Prerequisites: Node.js (^12.22.0, ^14.17.0, or >=16.0.0).

First, install the necessary packages:

npm install

Then, execute ESLint on a specific path:

npm run eslint -- path/to/analyze

If you are developing the coding standard itself or want a standalone installation, you can use one of the following methods:

Method 1: Clone the repository

git clone git@github.com:magento/magento-coding-standard.git
cd magento-coding-standard
composer install

Method 2: Create a standalone project via Composer

composer create-project magento/magento-coding-standard --stability=dev magento-coding-standard

To fix the use of helpers in a PHTML template, create a ViewModel and inject it into the block. You can then access the ViewModel in the template using $block->getViewModel() or $block->getData('viewModel').

<!-- Before: Using a helper -->
<?php $_incl = $this->helper(<helper_class>)->...; ?>

<!-- After: Using a ViewModel -->
<?php $viewModel = $block->getViewModel(); ?>
<?php // or
<?php $viewModel = $block->getData('viewModel'); ?>