What is the best-practice Project structure to use? Should I use one git repository per package, or a shared one for my whole project?
Answer
We suggest to keep the number of Git Repositories as small as possible. In a nutshell:
Start with a single Git repository for your whole distribution, where you also maintain the packages you create when kickstarting the project.
As soon as you need a package across multiple projects, start to separate them into different git repositories.
(TODO: write some more how the single-git-repository-approach works; i.e. .gitignore and dependencies of embedded packages)
Historic Background
When we started with Flow, many of us created a single Git repository per-package - which however proved quite cumbersome and hard to maintain. That’s why we switched to the different mode only having as little git repositories as possible.
@christianm / @christopher: you also discussed stuff related to such a setup in a different thread about the Neos site. Last remark of @christianm there is
IMHO it would be important to have a consistent composer.lock AND composer autoload information even if we don’t use it now.
What exactly is the issue with the composer autoload information? As I really don’t see the point of the consistent composer.lock as in the end all dependencies are locked in git including the lock file. So there’s always a consistent state between the composer.lock and package that are just available in the git repository.