1

I am trying to split my project up into multiple sub projects, all version managed so others can develop with me and we can easily divide tasks and track time across the project etc blah blah.

I have found myself in a situation where some of these sub projects depend on each other.

In isolation these projects don't do much, in order for them to be run they need to be installed into the main project.

I have a composer.json for each of the sub projects and where a sub project depends on another sub project I include it.

Because my project is getting bigger, whilst developing each of these smaller sub projects I'm finding that composer takes a copy of the dependencies, so each sub project now contains all of the other sub projects.

Not only am I getting sick of typing sub project, I'm sure there is a better way?

So what I'd like (this might not be what I should be doing) is a way to have each of these sub projects version controlled by git and able to find the other sub projects without having composer create a massive amount of duplication and as a bonus not having to composer update each time I make a change in one of the sub projects. Id like a seperate git repo for each sub project. I also don't want to alter my code to include local directories to autoload the classes, Im trying hard to keep composer managing all this.

You could argue that if anyone was actually developing a sub project they would in fact get the main project and update the sub project git repos inside that main project, then push those changes to the master branch for that sub project once they were done.

Have I just answered my own question?

One caveat to this is what if I don't want to give access to the main project to a developer because we have someone who will test the sub projects inside the main project?

How could I achieve this?

JackWhiteIII
  • 1,388
  • 2
  • 11
  • 25
Tom Shaw
  • 73
  • 9
  • This seems to answer my question but I didn't want to pollute code just for the sake of development and testing.http://stackoverflow.com/questions/25438287/how-to-configure-a-composer-package-to-be-globally-installed – Tom Shaw Jul 12 '15 at 00:02
  • Not sure if this is what you are looking for, but try to always keep the composer.json in both sub and main repo same and do .gitignore on vendor folder so that the developer will load the dependencies on his local machine everytime you update the composer.json – Blkc Jul 12 '15 at 00:37
  • The way I think Ive decided to go is to allow access to the entire project to all of the developers. Its a bit of a funny project in itself as we we are essentially developing a framework, an extension to the framework and busing a project using the framework and the extension at the same time. – Tom Shaw Jul 12 '15 at 20:09
  • Composer doesn't have a problem with circular dependencies, but your architecture has. You should be concerned that your framework becomes an unmanageable mess. My first impulse: Why do you split stuff into single packages if they all need all other packages? I won't be able to use just that one package, because I'd have to install all of them. Think about which tasks each package has to fulfill, and strip away anything else. Perhaps you should try and explain why all of your sub packages depend on each other to get a solution for that problem. – Sven Jul 13 '15 at 00:08
  • Excellent comment Sven. I think the point I may have failed to stress enough is we are developing three different products at the same time. So normally yes, Id agree. But in terms of keeping these products distinct in their development environments is important even if they require each other to run. – Tom Shaw Jul 21 '15 at 01:43

0 Answers0