In what case we need to run this command magento setup:di:compile ?

  • Once you have installed new modules and want to clear some directries – Jaleel Mar 2 '16 at 6:47
  • and anything else? – MrTo-Kane Mar 2 '16 at 7:04
  • Also when you switch to production mode because in that mode, no static content is generated; it's all served from pub/static – Steve Johnson Mar 2 '16 at 18:01
  • During deployment (i.e. when changes were made to a system in production mode)

    Note that in production mode (versions 2.0.5 and earlier) you must use the "multi-tenant" compilation. Fixed in 2.0.6 and later.

    bin/magento setup:di:compile-multi-tenant

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

  • You can also use compilation in development mode, which should speed up the site, but on the other hand it slows down development, because you will need to run bin/magento setup:di:compile everytime you added new classes with dependencies (constructor parameters) or changed dependencies of existing classes.

    This is optional, and it's probably not a good idea. If you already ran the compilation in your development environment, delete the files in var/di to disable it.

| improve this answer | |
  • 1
    setup:di:compile-multi-tenant has been removed – Antonino Bonumore Jul 18 '16 at 15:59
  • Can we please get some confirmation as to whether deleting the var/di folder trick works? It doesn't seem to for me – Wildcard27 May 11 '17 at 5:02
  • @Wildcard27 what if you also delete the directories in var/generation? – Fabian Schmengler May 11 '17 at 6:18
  • @FabianSchmengler Have just created an Action to test. -- Loaded the page, error. -- Deleted di and generation folders, reloaded, works. -- Add new dependency, reload page, error. However no di folder is generated. -- Delete generation again, reload, works. Conclusion: Delete the generation folder after adding dependencies and you won't have to run setup:di:compile. If someone else could confirm this, that'd be awesome. – Wildcard27 May 11 '17 at 8:00

As per my comment on another answer:

You can avoid running the setup:di:compile command after every time you add a depency by just deleting the var/di and var/generation folders before reloading the page.

From my own tests, Magento will recreate the var/generation folder, but not the var/di folder until setup:di:compile is ran again. This means you should only have the var/generation folder to delete.

Funnily enough, this also works with pub/static/* and setup:static-content:deploy. This is because Magento seems to create symlinks to the files needed if the static content is built by page reload, rather than CLI.

People in our office were having problems running the above commands whilst using Docker for Mac. The file processing was just too slow. By using the steps above, development should be much quicker.

It's probably best to note that this will not work when in production or default mode. This is only for development. As mentioned by Fabian Schmengler, initial page reload will be slower than normal, but shouldn't be as slow as running setup:static-content:deploy or `setup:di:compile.

For reference, I am running version 2.1.5.

| improve this answer | |

Taken from Alan Storm's blog.

Dependency Injection Compilation

To start, we should explain the problem these commands are trying to solve. When you ship a Magento 2 system to production, you need to run the following command

php bin/magento setup:di:compile

This commands scans through the code in your system and pre-generates a number of things (mostly related to the object manager system and dependency injection) that Magento dynamically loads when you’re running in developer mode. This is both a performance and security thing, and discussing it in full is beyond the scope of this article.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.