Version control¶

Add to version control system¶

If you use a version control system such as Git (and you really should!), it is important to add both files composer.json and composer.lock (which were created automatically during the previous steps). The composer.lock file keeps track of the exact versions that are installed, so that you are on the same versions as your co-workers (and when deploying to the live system).

Note

It is always good practice to exclude passwords from checked-in files (for example, config/system/settings.php). A solution may be to add the setting containing sensitive information to config/system/additional.php and use an .env file in the project directory to configure the password and other configuration along with helhum/dotenv-collector.

Additionally, some files and folders added by Composer should be excluded:

public/index.php
public/typo3/
public/typo3conf/ext/
vendor/

A .gitignore file could look like this:

/.gitignore¶

/var/*
!/var/labels
/vendor/*
/public/index.php
/public/typo3/*

Checkout from version control system¶

All your co-workers should always run composer install after they have checked out the files. This command will install the packages in the appropriate versions defined in composer.lock. This way, you and your co-workers always have the same versions of the TYPO3 Core and the extensions installed.

Maintaining versions / composer update¶

In a living project, from time to time you will want to raise the versions of the extensions or TYPO3 versions you use.

The proper way to do this is to update each package one by one (or at least grouped with explicit names, if some packages belong together):

typo3_root$¶

composer update georgringer/news helhum/typo3-console

You can also raise the requirements on certain extensions if you want to include a new major release:

typo3_root$¶

composer require someVendor/someExtension:^3.0

For details on upgrading the TYPO3 Core to a new major version, please see Upgrade the Core.

While it can be tempting to just edit the composer.json file manually, you should ideally use the proper composer commands to not introduce formatting errors or an invalid configuration.

You should avoid running composer update without specifying package names explicitly. You can use regular maintenance automation (for example via Dependabot) to regularly update dependencies to minor and patch-level releases, if your dependency specifications are set up like this.

After any update, you should commit the updated composer.lock file to your Git repository. Ideally, you add a commit message which composer command(s) you specifically executed.