Composer is an excellent way of managing dependencies but in order to use it properly it does require a build and deployment process.
The two ways of deploying a site built with composer is to either generate an artefact with the composer dependencies installed, or to install composer as part of the deployment process. Both of these approaches require not committing the vendor directory and other third party libraries (like Drupal core for example) to the git repository.
Many developers tend to go for the approach of committing the composer dependencies to the repository in order to simplify their workflow. This approach, while simple, does have its problems. I have talked about the problems of committing the composer vendor directory in detail in a previous article.
If you need to swap from a vendor in git approach to a deployed application approach then there are some thing you'll need to do in order to remove those directories from your codebase.
The best way to remove the vendor directories from your codebase is to automate it. This means that if you ever want to test your deployment process then you can run a single command to remove all of the non-custom files. This is also a useful way of triggering a full re-install of the project.
Create a file called nuke.sh and add it somewhere in your project (preferably outside of your webroot). This file contains a number of deletion (i.e. rm) commands that go through your codebase and removes any vendor, Drupal core or contributed code. I normally create this file in "scripts/nuke.sh".
# Delete Drupal core and any contrib directories.
rm -rf web/core
rm -rf web/modules/contrib
rm -rf web/themes/contrib
# Delete Drupal root files.
rm -f web/.csslintrc
rm -f web/.editorconfig
rm -f web/.eslintignore
rm -f web/.eslintrc.json
rm -f web/.gitattributes
rm -f web/.gitignore
rm -f web/.ht.router.php
rm -f web/autoload.php
rm -f web/example.gitignore
rm -f web/index.php
rm -f web/INSTALL.txt
rm -f web/robots.txt
rm -f web/README.txt
rm -f web/update.php
rm -f web/web.config
# Delete any Drupal scaffold files.
rm -f .editorconfig
rm -f .gitattributes
# Delete any third party libraries.
rm -rf web/libraries
# Delete the vendor directory.
rm -rf vendor
echo "Deleted third party libraries."
Make sure you give execute access to this file so that you can run it. You can do this using the chmod command.
chmod +x scripts/nuke.sh
If you aren't tracking mode changes (i.e. file permissions) in git (which is a good thing) then you will need to also tell git that you want this file to be committed as an executable file. This can be done using the update-index git command.
git update-index --add --chmod=+x scripts/nuke.sh
With the script in pace you can now add it to your composer.json file. Add the following section to your composer.json file. If you already have a "scripts" section in your composer file then just add the "nuke" command to it.
"nuke" : "scripts/nuke.sh"
You can now delete the vendor directories of your project by running "composer nuke".
After running that command your codebase will have quite a lot of changes in it. Before adding those changes you'll want to add them into your .gitignore file. This will prevent the files being added back in the future by mistake.
Add the following section to your project .gitignore file.
Note that the .htaccess in this list is optional. Some sites will have custom rules added to this and so you may want to keep that in with the custom rules applied.
You still need to remove all of the removed files from git, there are a couple of ways to do this.
Since this is a one off thing that you will probably not run again you can run the "git rm" command with the --cached flag and just feed in the files and directories that need to be removed.
git rm --cached vendor web/core web/modules/contrib
Alternatively, you can use a git sub-command to list all of the files that are ignored in the .gitignore file and remove them in a single command.
git rm --cached `git ls-files -i -c --exclude-from=.gitignore`
With that done you can now commit the change. If you are migrating a repository over to use composer deployment processes then this will probably create many thousands of file changes. That many deletions makes code review impossible, but your team should know the intent of the commit and how to get their local projects up and running again.
This technique is a good idea to add to any existing project as well since it gives an easy way to delete and re-download the composer files. It does mean that you need a deployment process before hand, but with packages like Deployer you can easily set up robust deployment systems for Drupal that will run composer install as part of that process.