I'm developing a ZF2 app that will make heavy use of feature specific modules.
While modules will be as atomic as possible, certain modules will be dependent on other modules existing, and nearly all modules will require at least one core module to exist in order to function. However, this application is going to be deployed to several different sites, and not all sites will have all modules. Some sites will have modules that other sites don't have. It's important that I am able to easily manage modules per site without a code change and without forking the codebase off for individual sites. Ideally, I'd love to manage these modules using composer. It seems like in an ideal world I would have a base composer.json-dist with the basic modules that all site deployments would have, and then that file would be copied and modified as necessary as part of the install/update process. Then each module itself would have it's own composer file that would be used to track it's own dependencies (which would also lend itself nicely to handling third party libraries, too). Where I start to get lost is the development workflow for the application. Each module will need it's own repository, but I don't want to have to open up one codebase per module - ideally I want to develop in a single codebase that would contain the application and all modules, but still allow me to commit and push individually to each module repo. Is there a good way to do that? Maybe I'm going at this the completely wrong way and there's a better way to achieve what I'm looking for. If so, I'd love to hear it. -- View this message in context: http://zend-framework-community.634137.n4.nabble.com/Best-practices-for-managing-ZF2-modules-and-dependencies-tp4662454.html Sent from the Zend Framework mailing list archive at Nabble.com. -- List: [email protected] Info: http://framework.zend.com/archives Unsubscribe: [email protected]
