Hi everyone, Thank you all for the fantastic advice. I am now working on implementing a solution that uses --prefer-source and I'm running into two problems that Google didn't solve.
I apologize as these are more composer specific than Zend, but it sounds like several members may have experience with this already. - Is there a way to set --prefer-source on a per package basis? I found the config stub option for composer.json, but that seems to affect all packages. - Like the first question, is there a way to set a specific directory for the checkout of specific packages? For example, I'd love to clone the custom modules into the module directory instead of /vendor. Again I see how I can set this globally, but I'm unsure if this can be done on a per package basis. Thanks, -Andy On Thu, Feb 12, 2015 at 1:10 AM, Michael Gooden <[email protected] > wrote: > Hi, > > You could also take the approach similiar to Zend Framework 2 itself, > wherein all the code lies in a single repository, with a master > composer.json that does a "replace self.version" for all your modules. You > use this during development with --prefer-source, which should make it easy > to develop the code. > > In parallel, you maintain composer.json files within each module path that > describe the dependencies of that specific modules. For production > deployment, you use the script that ZF2 uses, to break the main repo into > individual composer repositories. > > I must say, Vincent's approach does seem more structured than this. YMMV. > > > Kind Regards, > > *Michael Gooden* > CEO > > > *Blue Point Events (Pty) Ltd* > > Jutland Crescent, St Georges Park, Port Elizabeth, 6001 > > PO Box 63941, Greenacres, Port Elizabeth, 6057 > > M: +27 76 489 1764 | F: +27 86 551 2556 > > [email protected] > > Skype: michael.bluepointweb > > *NOTICE OF CONFIDENTIALITY* > The preceding e-mail message (including any attachments) contains > information that may be confidential, may be protected by the > attorney-client or other applicable privileges, or may constitute > non-public information. It is intended to be conveyed only to the > designated recipient(s) named above. If you are not an intended recipient > of this message, please notify the sender by replying to this message and > then delete all copies of it from your computer system. Any use, > dissemination, distribution, or reproduction of this message by unintended > recipients is not authorized and may be unlawful. > > On 12 February 2015 at 02:48, Vincent Caggiari <[email protected]> > wrote: > >> Hello, >> >> We tried exactly the same thing (same modules for different clients) but >> things got so complicated to manage that we stopped to build websites this >> way. >> Why it became so complicated : >> >> - Same code base for different clients doesn't allow you to customize >> them so when a client has a specific use case/need, you can't do it >> (and >> don't tell me that you will create a new module for this client which >> will >> override the first one for the parts you need to customize because you >> will >> have 2 modules doing the same thing and when you will have to do some >> changes, you will not remember in which one to look). >> - You MUST have one repository per module, it's easier to manage and >> see >> what your developers are doing. If you need to update only one module >> (i.e >> patch), you can then update your project easily with only the change >> you >> need (so you don't pull changes made on another module which can >> introduce >> bugs for a specific client or some merging headache). >> >> >> At this time, we have one repository per module. Each module for each >> client is forked from our "module" core codebase so when a change is made >> for a client and can be used by another (generic change), you update your >> client module, then make a pull request to the "module" core codebase >> which >> is then approved and incorporated. >> Then, when you need to work on another client which use the same module, >> you update your client's one by pulling the "module" core codebase, merge >> the changes with the customized one, test and voila. >> >> Regards, >> CAGGIARI Vincent. >> > >
