Magento 2 and git, best practice for custom module development

Question

I have trouble wrapping my head around a very particular issue concerning a development setup for magento 2.

I have read a lot about using composer and git. It makes a lot of sense to NOT include the vendor directory and have each module, theme and custom project in separate repositories.

To explain my issue it is best I explain my workflow.

Currently I am working on a customer project. I installed magento and a couple of modules via composer. In addition I have my own set of custom modules I am developing while creating this project. Those modules of course reside inside the app/code folder. Some are project specific and will never be reused elsewhere. Those should be part of the project's git repository.

Others WILL be reused in other projects. Therefore I want them to have their separate repository. But since they are work in progress I cannot hook them into the project like all the other modules via composer (or can I?). It is actually the other way round, I will need to commit from this current project into the repository. And this process is likely to continue when I use those modules in other projects. These modules will continously be improved.

So what would this scenario look like? In the project's root folder I would have the main project with it's own remote repository. Let's say during the course of this project I have developed three custom modules inside app/code. How would I maintain those so they will be committed and pushed into each of their repository? Would I need to set up a repository in each of the modules folders? Would I have to cd in all of them and add/commit/push individually?

I fear I might loose oversight of the state of all the modules this way.

Let's say I finish this current project but in my next project I add new features I want in my first project as well. How would I "backport" those new features into past projects?

Practical insight welcome :)

Thank you

Answer 1

You can add the local path to the module you'll be distributing to your composer.json. You can then work either in the vendor directory or in the path you've defined.

Example: composer.json

"repositories": [
  {
    "type": "path",
    "url": "../../packages/my-package"
  }
],
"require": {
  "my/package": "*"
}

Once you're preparing the customer projects release you should ensure your module is published in a none local repository with the appropriate tags (GitHub, Packagist, Satis, etc). You can then lock down the version number in your customer project's composer.json and remove the "repositories" section for this module.

Edit:

Further to this, you can use the glob pattern to define paths, which really helps when building an application/library with separate components.

If you had a directory structure such as this:

.composer
└── packages
    ├── package-1
    │   └── composer.json
    ├── package-2
    │   └── composer.json
    ├── package-3
    │   └── composer.json
    ├── package-4
    │   └── composer.json
    └── package-5
        └── composer.json

then defining your local repository path as:

"repositories": [
      {
        "type": "path",
        "url": ".composer/packages/*"
      }
    ],
    "require": {
      "my/package-1": "*",
      "my/package-2": "*",
      "my/package-3": "*",
      "my/package-4": "*",
      "my/package-5": "*"
    }

Would allow you to install all those components during the development stage of a project.