Magento2 - setup:di:compile

The command setup:di:compile command generates the contents of the var/di folder in Magento <2.2 and generated for Magento >= 2.2

According to Magento, this serves the following purpose:

  • Application code generation (factories, proxies, and so on)
  • Area configuration aggregation (that is, optimized dependency injection configurations per area)
  • Interceptor generation (that is, optimized code generation of interceptors)
  • Interception cache generation
  • Repositories code generation (that is, generated code for APIs)
  • Service data attributes generation (that is, generated extension classes for data objects)

Source (http://devdocs.magento.com/guides/v2.0/config-guide/cli/config-cli-subcommands-compiler.html)

However, when you place Magento in production mode, without compilation it indeed still works. So according to the Magento docs this is more an optimization step (that is, optimized code generation of interceptors)

When we have errors in the setup:di:compile command, this is mostly because of errors in one of the constructors of custom php classes.


It's not mandatory to run setup:di:compile command everytime but if you have done any code change specially with factory methods ,proxy, add plugins or any code compilation then you must need to run this command.

More Details

magento setup:di:compile in order to generate necessary files. Both options ends up with generating classes in MAGENTO_ROOT/var/generation directory (or /generated if Magento 2.2+).

What classes are generated?

  1. Factories
  2. Proxies
  3. Plugins

Factories

Factories are used to instantiate objects that can not be injected automatically. For example, a product object has to be loaded from the database, but dependency injection container doesn’t have enough information to create this object. That’s why we use factories.

Proxies

Magento 2 uses constructor injection in which all dependencies are required. You cannot instantiate an object without passing all dependencies. What if you’d like to have optional dependencies? That’s why proxies exist.

Plugins (Interceptors)

Simply put, plugins are the primary customization mechanisms for Magento 2. No more class rewrites. It allows you to hook in and do something before, after or around any public method of the application.

when you run setup:di:compile command it do below things

Code compilation consists of all of the following in no particular order:

  • Application code generation (factories, proxies, and so on)

  • Area configuration aggregation (that is, optimized dependency injection configurations per area)

  • Interceptor generation (that is, optimized code generation of interceptors)

  • Interception cache generation Repositories code generation (that is, generated code for APIs)

  • Service data attributes generation (that is, generated extension classes for data objects)

Refer this answer for when we should run which commands: https://magento.stackexchange.com/a/184927/35758


Magento will still run in production and dev without the di:compile command. It will actually compile the Interceptors as it needs to and store the in the generated folder.

Even if it works, that does not mean you should skip this step! In fact, when this is ran, magento also checks for duplicated injections, dependency loops and other fundamental steps that will make your site more stable and less likely to crash and !die.

I strongly believe that that error is due to the use of a class that Magento can't compile due to some wrong constructor argument.

The error you posted is pretty vague, but I believe you have a class that extends the AbstractView class, 99% it's a block somewhere in your custom modules that does not pass the correct arguments to the parent::__construct() method. Hence when instantiated it fails.

Note that all blocks extend the AbstractView class so you'll have to execute the compile command with xdebug on and set a log at look at the stack trace to see what class called it last before it failed.

The fact that the site runs without that error means that you're not actually using the corrupted block anywhere on your page, but Magento will still try to compile it when running the compile command, hence it fails.