So I can't quite figure this one out. We have an API as a composer project.
No we which to add functionality to this API in a modular fashion creating separate composer projects for each module.
But how do I resolve dependencies while developing? Each module need access to the "core" API project to be able to test out code.
The current API is not a real composer package yet. But my initial thought is to create a new package for the module I'm about to develope, and then add a dev-dependency for the "core" API.
Or how should I do it?
Are your modules standalone resp. without the "Core" package usable?
I suppose not, so the "Core" module is a dependency for each of your modules.
Ergo the "you/core" package needs to be in the require block of composer.json of every module.
Note that this is not a dev-dependancy then, because i suppose your module wouldnt be usable without the core package.
Phpunit is a classic dev-dependency because the functionality of your module would still work if there would be no phpunit.
To test & develop the module, you would run a composer install in your module project folder to fetch all dependencies into a vendor folder. Then you can develop and have all your dependencies present. You would need to require the composer autoloader, though. F.e in your phpunit.xml.dist.
Dont forget to add vendor to your .gitignore
Related
I'm trying to add a missing feature to a bundle. Here is what I've done so far:
Spoke to the project owner and got their approval
Created a fork and cloned it locally into a directory outside of my project
Made a feature branch
Ran composer install
Now, the question is, how can I include this into my own Symfony project so that it would be autoloaded? I want to test my changes inside my own project before I send a pull request.
See How to require a fork with composer, to be specific, require a VCS repository as described in Composer docs
Or a bit faster way for improving developing process (which is independent on Github), try using local repositories.
You can archive in two manner:
You can hack the vendor folder replacing the folder of the bundle with a symlink of the third-party bundle
[RECOMENDED] Put in the composer.json file of your project the reference of your personal github project instead of the official version
I have project with this scheme:
main project depends on subprojects
subproject 1 with some own dependencies
subproject 2 with some own dependencies
subproject 3 with some own dependencies
I'm curious if I can use composer to do job. I would like that packages (subprojects) with type "project" behave like standalone project, not like library.
I found workaround, if in main project composer.json provide/replace all dependencies from subprojects, I can use composer install/update and don't bother about conflicts. I can use custom installer to put subprojects in proper directories and plugin or script to install dependencies for every subproject. This works but is quite hard to maintain, if any subproject adds dependency I need to modify main project composer.json.
Is way to use composer for this task or I should abandon idea write simple tool? What do you think?
If I want to create a module inside the vendor folder, what are the git commands to create a subtree (or somehting else)?
Scenario:
I update the module
Push it to github
My colleague wants the update too, should he pull from github, or just update composer?
Then he has to make his own changes and push them too github
I tried some solutions but I felt like they where not the best, how does everybody else do this?
Scenario:
I want to override some view files from an existing module and create my own module for this (yes it has to be a module), extending from the original module
Do I need extra steps for this? And a separate composer package?
How can my colleague install this module and make some changes?
If you want the module to be accessible to everybody the easiest way to do this is to create a composer package for it. Then you just add it to the composer.json file and you can both use the package just by doing a composer update.
Remember to tie the git repository to packagist (through webhooks, when you create the packagist package you will see instructions), so each time you update git, an update to packagist will be available.
To push an update the module just browse to that particular path and do a commit / push to git like any other package.
If you do not want to create a packagist package, then you can always create a repository like this in composer.json Use PHP composer to clone git repo.
Without using Composer, is it possible to download a repository in Github along with it's defined composer packages?
For example: FluxBB 2 requires Laravel 4.
I was hoping to download FluxBB and at the same time the packages of Laravel 4 without using Composer.
Usually projects that use composer will ignore 3rd party components. In .gitignore you will see /vendor. This is the place where Composer downloads its dependencies.
This will find the latest version of monolog/monolog that matches the supplied version constraint and download it into the vendor directory. It's a convention to put third party code into a directory named vendor. In case of monolog it will put it into vendor/monolog/monolog.
Tip: If you are using git for your project, you probably want to add vendor into your .gitignore. You really don't want to add all of that code to your repository.
http://getcomposer.org/doc/01-basic-usage.md#installing-dependencies
Doing it manually is a bit of a hassle. Composer uses packagist to get its files (if you look at a package it has a source added to it Laravel https://packagist.org/packages/laravel/framework).
Composer auto loads the needed files automatically so its a big time saver.
For libraries that specify autoload information, Composer generates a vendor/autoload.php file. You can simply include this file and you will get autoloading for free.
require 'vendor/autoload.php';
This makes it really easy to use third party code. For example: If
your project depends on monolog, you can just start using classes from
it, and they will be autoloaded.
http://getcomposer.org/doc/01-basic-usage.md#autoloading
We created a ZF2 project with skeleton app and it works fine for a simple test application. Now we are working on a real project. My question is what we should store in the repository (SVN), the whole project structure or just the new source code? ZF2 comes with a vendor directory which is almost 31MB in size (which has the ZF libraries). Should we store the whole vendor folder in SVN?
This is the first time we are using PHP and ZF so are not clear in how we will deliver the complete project to production from SVN. Also what is the build process if at all exists. Any clues/links to "ZF2 project packaging" is appreciated.
No, don't include dependencies in your repository! Putting your dependencies under version control doesn't do any good, it just blows up your repo for no reason.
You want to add the skeleton to your repository and your own library but definitely not the framework or any other dependencies.
The way to go is to use composer for dependency installation and some kind of build tool like Phing to automate installation of your project.
See the relevant chapter on phptherightway for more information on how to build your application.
The most simple build process doesn't even need a build tool
checkout your project from SVN/git
run php composer.phar install to install the needed dependencies (defined in your composer.json)
But most probably you want to do some more stuff like setup up the environment, deleting some files, etc.
A word about ZF packages. They're not available from packagist but you can install them with composer anyways. You just have to add the dedicated repository to your composer.json as described here: http://framework.zend.com/downloads/composer