After doing some more searching I came upon this: https://getcomposer.org/doc/faqs/how-do-i-install-a-package-to-a-custom-path-for-my-framework.md
I ended up implementing this and it worked perfectly having my package use composer/install with the "zend-module" type. Thanks for the help all! On Wed, Mar 11, 2015 at 11:09 PM, Andy Baird <[email protected]> wrote: > 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. >>> >> >> >
