[FIXED] Developing extensions in a TYPO3 Composer project

Issue

Summary: How to setup an (existing) TYPO3 Composer project for developing custom TYPO3 extensions (that are used in that project)? How to handle extensions not specific to the individual project, which may be in several projects.

---

I have a Composer TYPO3 project for our site. Relevant files (such as composer.json, composer.lock, LocalConfiguration.php are included in the Git repo)

The question is how to develop own custom (currently non-public) extensions and setup the development instance.

It seems, the solution of choice for the extensions specific to the project is to include them in the project repo, e.g. in a folder /extensions and adding them using repository type=path like this:

composer.json:

"repositories": [
    {
        "type": "path",
        "url": "extensions/*"
    },
...
"require": {
    "myvendor/myextension": "@dev",
    ...
}
 

For extensions used only in this project this makes sense to me.

What do I do with extensions that are not specific to this project? They are used in other projects as well. For example, there might be a bug which is reproducible in my project - so I would like to debug and develop on the extension in this project. Same goes for creating PR for public extensions of other authors.

What I currently have for the custom extensions: They have their separate git repositories (private Gitlab), are tagged for releases and required with version tags.

composer.json (incomplete)

{
  "repositories": [
    {
      "type": "gitlab",
      "url": "git@gitlab.mysite.org:typo3-extensions/my_extension.git"
    }
  ],
  "require": {
    "myvendor/my-extension": "^1.3.1"
  }
}   

This setup is not suitable for using the same git repository to setup the development site and develop extensions on this (as the custom extension are fetched from Gitlab by Composer without the .git files).

Solution

To me, the most straightforward solution seems to be to create a new branch in the extensions' repository starting at the commit/tag/version that is currently used in the specific problem.

Set the required version in the project to the new branch and start hacking away at the problem till you find a solution.

Then you can consider merging the changes back into master or keep a separate branch for this project which receives updates from master.

Answered By - Sascha