Best Practices

A number of general best practices have been moved to Working With Composer . The sections specific to migrating to Composer are still here.

Completely Clear typo3conf/ext Folder

In the “Migration Steps” chapter, this tutorial explained, how you can keep your individual extension in “typo3conf/ext” and in the “Co-working” section, there was a part about how to add rules to your .gitignore file to exclude typo3conf/ext from, but keep your individual extensions in Git.

If you are searching for a solution to keep your typo3conf/ext folder clean and unify the extension handling even for your project’s individual extension, this section might be useful.

Define a Local Path Repository

Create a directory packages in your project root folder and define this folder as a repository of type “path” in your composer.json :

{
    "repositories": [
        {
            "type": "path",
            "url": "./packages/*"
        }
    ]
}

Include Your Individual Extensions From packages Folder

In the next step, you move all your individual extensions from public/typo3conf/ext to packages . And for this way to include them, it’s important, that each extension has it’s own correct composer.json file. How this file should look in your extension, can be found on composer.typo3.org or this blog post from Helmut Hummel .

Assumed, your package key is, foo/bar , you can type the following command to include your extension to your project:

composer require foo/bar:@dev

In this case, it’s the easiest way to not define any composer version number, but tell composer to use the latest dev state.

Note

The autoload information now comes with the extension’s composer.json and can be removed from your project’s composer.json .

Exclude typo3conf/ext from Version Control System

To finish your cleanup of “typo3conf/ext”, you should keep the line /public/typo3conf/ext/* in your .gitignore , but remove all lines, starting with !/public/typo3conf/ext/ .