Deploying a Composer Managed Drupal application

Acquia and Composer best practices dictate that you should not commit Composer dependencies (like vendor, docroot/core, docroot/modules/contrib, etc.) to your git repository.

You may ask yourself: "If I don’t commit them, how do I deploy them to a hosting environment?" That’s a good question. To answer it, let’s talk about a common and fundamental software development concept: production as an artifact of development.

Many software languages compile source code (used during development) into an artifact (used during production) using a build process. For example:

• SASS and LESS are compiled into CSS
• Typescript and REACT JSX are “transpiled” javascript

Why do this? In short, because you want your hosted Drupal site to be slim, fast, and secure. Your production environment should not contain any development tools or configuration. The things that you need to develop Drupal are not the same things that you need to run Drupal.

For example, you make use any one of the following tools during development and testing of a Drupal application:

• Local environment configuration, like a Dockerfile or Vagrantfile
• Code quality tools like PHP Code Sniffer
• Front end tools like SASS, LESS, Gulp, Grunt,etc.
• Testing tools like Behat, PHPUnit, etc.

You shouldn’t ship these tools or their configuration to your production environment!

Let’s visualize the difference between your "source code repository" and the "artifact" that you will actually deploy to your production environment.

Note two things:

1. The development "source code" contains config files for development tools that are not present in the artifact.
2. The artifact contains upstream dependencies (like modules, Drupal core, etc.) that are not committed to the “source code” repository.