I am working on a large project with a lot of git repositories. I can easily keep them in sync like this:
https://getcomposer.org/doc/05-repositories.md#path
"repositories": [
{ "type": "path", "url": "../another-component" },
{ "type": "path", "url": "../yet-another-component" }
]
If I run composer this will create a symbolic link inside my vendor folder for each repository provided. This way whenever I update one of the repositories outside my main app repository changes will be reflected immediately.
This is a perfect local development solution but on production I would just like to have a composer file that points to the online Github repositories and pull the repositories from Github.
Of course this composer file would look a bit different since the types would be set to vcs and the url's would point to Github instead of being relative paths.
How do people do this for local/production setups? Do you just maintain 2 separate composer files, one for local development and another for production?
This would mean whenever I add another repository to my codebase I have to remember to update it in 2 places or my entire codebase breaks down.
Since it seems your components are already hosted online, I would recommend to just let composer pull them down from Github and manage them like any other dependency, be it from development or production.
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 a Github repository, which I recently submitted to Packagist. The top-level directory of my repository is as follows:
build/
bootsole/
examples/
licenses/
screenshots/
The bootsole subdirectory is the actual directory containing the classes that are managed/autoloaded by composer.
I tried creating a new project, to test the package. In the new project, my composer.json is as follows:
{
"require": {
"php": ">=5.4.0",
"alexweissman/bootsole": "0.2.0"
}
}
I run composer install, and it fetches bootsole and its dependency, valitron. However, it places bootsole in vendor/alexweissman/bootsole/, and what's more, it places the entire repository in that directory - not just the bootsole subdirectory.
Is it possible to configure a package to only include the contents of the subdirectory bootsole (i.e., omit build/, examples/, etc)?
Update: This question seems to suggest that it isn't possible (though the question is over a year old at this point). It suggests that I tell git to ignore the other directories in the archive, which I'd rather not do for the benefit of developers who don't use composer.
Is there perhaps a way to create a separate branch that contains only the bootsole/ subdirectory, point Composer to that branch, and somehow auto-synchronize Composer's branch with the master branch?
Whatever you run composer install on, or composer require on will generally be put in the vendor directory. Composer essentially owns the vendor directory. There are ways to put these items elsewhere, but it defeats the purpose of composer, which is to help you manage version changes in all your interacting libraries.
However, another option is to run composer create-project. This will essentially clone the project to wherever you tell it, and then load up everything in the require section of the composer.json file. My guess is that you want two projects, one for the initial install of all the directories that you will tell your user to run composer create-project on, and another that will be just the bootsole directory, which you will require in the first project's composer.json file, and which will be put in /vendor/alexweissman/bootsole. You will need to change your code to look for the bootsole directory there.
Background
I'm developing a series of websites which share a common engine. Something very similar to StackExchange's network of websites. Every webiste is a separate Symfony2 installation on a different Git repository, with a dependency to the engine, which is also placed on a separate repository.
"requires": {
...
"my-platform/core": "dev-master"
}
I'm still in the early stage of development, so I'd like not have to use composer update everytime I change something in the core repository. It seems that Composer has a right tool to solve this problem but it doesn't want to work properly.
My directory structure:
Workspace
MyPlatformCore
src
MyPlatform
Core
SomeClass.php
composer.json
MyWebsiteAAA
app
src
vendor
web
composer.json
MyWebsiteBBB
app
src
vendor
web
composer.json
Autoload section from composer.json from every MyWebsiteXXX repository:
"autoload": {
"psr-0": {
"MyPlatform": "../MyPlatformCore/src"
}
},
Problem
If i run php composer.phar dumpautoload --optimize from MyWebsiteXXX it generates files of autoloader with wrong paths. File vendor/composer/autoload_classmap.php contains:
'MyPlatform\\Core\\...' => $vendorDir . '/myplatform/core/src/MyPlatform/Core/...php',
while it should contain:
'MyPlatform\\Core\\...' => $vendorDir . '/../MyPlatformCore/src/MyPlatform/Core/...php',
P.S. Workspace\MyPlatformCore is in fact a symlink, but it should matter, isn't it?
Composer does not fit your current phase of work.
Having a working PSR-0 autoloader for your core classes will make them available to your other code. Adding this autoloader to the Composer autoloader should work, but I think it is better to integrate your core "code in progress" via symlink instead of constantly composer-updating it.
The real benefit would be with an existing core codebase in several tagged versions, and your multiple websites using defined versions that differ from each other. You would only work on the core if there are features to be added or bugs fixed. The daily work would go into any of the websites, which might include updating this websites core files when it is time to do so.
I'm looking to develop a package in PHP, but I don't want it immediately available on GitHub or somewhere. It's easy enough to include a Packagist file in my composer.json, but how do I add a local package into my composer.json? Also, should I be building the package in /vendor/foo/bar (relative to the root composer.json), or should I put it somewhere else?
Edit: I guess my question is about how everyone else writes their packages. Does every new package get added to Packagist, and then when you want to test your changes, you commit to GitHub (or wherever), and then pull that back down via Composer? That seems really inefficient.
Instead of creating a new repository, you can tell composer to use any local path:
https://getcomposer.org/doc/05-repositories.md#path
For instance, lets say that you have your PHP projects under ~/devel/projects
You may have your main project in ~/devel/projects/main_project, and your "local package" in ~/devel/projects/local_package
Define your composer configuration for the local package. In ~/devel/projects/local_package/composer.json.
{
"name": "your_vendor_id/your_local_package",
...
}
Then, you can edit ~/devel/projects/main_project/composer.json and link to your local package via path repo:
"repositories": [
{
"type": "path",
"url": "../local_package",
"options": {
"symlink": true
}
}
],
"require": {
"your_vendor_id/your_local_package": "dev-master",
...
}
More info on this link (not written by me but has a good explanation on this subject):
https://carlosbuenosvinos.com/working-at-the-same-time-in-a-project-and-its-dependencies-composer-and-path-type-repository/
As this question has many different components/standards to be explained, I'll try to explain as much as possible here and you can PM me or just Google it for more specific questions as they come up.
To answer your first question, "How do I add a local package into my composer.json?":
If by "add local package" you mean autoload your class/package, you can do that by either using PSR-4 or PSR-0 or Classmap options in composer.
Read more
PSR [petermoulding.com] (via archive.org)
PSR-4 autoloading support in Composer [seld.be]
Battle of the Autoloaders: PSR-0 vs. PSR-4 [Sitepoint]
Why use a PSR-0 or PSR-4 autoload in composer if classmap is actually faster? [SO]
You can Google it if you need more info on PSR-0, PSR-4 and Classmap.
Example
"autoload": {
"psr-4": { "Core\\": "src/Core" } ## "standard": { "namespace" : "path/to/dir"}
}
Or (edit)
If you actually want to add a local package:
Create a composer.json for the local package, like:
{
"name": "localPackage/core",
"version": "dev-master"
}
You can also specify other properties and/or dependencies as required.
Zip the package, with the composer.json file as the root file in the archive.zip, and place it where desired.
In the other project/package where you want to include the local package, add the local package name to the required parameter, like
"localPackage/core": "dev-master"
Add the following under the repositories parameter:
"repositories" : [
{
"type": "artifact",
"url": "path/to/localPackage.zip"
}
]
Now if you have the local package on git, then there would be no need to archive the package (basically omit step 2) and you just need to replace the URL in the above example to the path/to/localPackage/.git.
(End of edit)
Now to answer the larger question: "How do I develop and include a Composer package?":
Decide the directory structure. Commonly it is as follows:
/PackageRoot
/src/PackageCore
composer.json ## this is your library’s composer.json
LICENSE
and set up your composer.json.
An example of one of mine composer.json files can be found at http://pastebin.com/tyHT01Xg.
Upload it to Github and tag the version. Use Semantic versioning (make sure you exclude/ignore the vendor directory when uploading to Github).
Register the package with Packagist (after logging in).
If you have tagged your commit as v1.0.0 (or similar), then this will show up in your Packagist dashboard for that package.
Now, if everything is done right, you should be able to use your library as a dependency in other projects by adding it to the composer.json of that project.
Here's a recap of the solutions plus my own
publish on packagist
Since you don't want to publish yet, you're in development, this is a poor option.
upload github
You may not want to publish your library source on github, not want to pay for a private repo, or be able to use a cloud external service (due to political or network policies).
zip your library
You can use the composer repository path in your example implementation to point to a local zip file as a release. You'll have to re-zip every time you make a change to the lib, even with a batch file to do it, this is icky.
upload to local git/svn repo on your machine
This is getting close, but you'll need to do a composer update each time you change your library and want to test your example implementation. This mimics productions but is cumbersome. Personally I recommend this solution, even though it's not brainless.
Autoload the library directly (sortof does what you want)
This is a hack, but you could just add:
{
"require": {
},
"autoload": {
"psr-4": {
"yourlibnamespace": "D:\\Code\\yourlib\\src\\"
}
}
}
Please note that you will need to copy+paste the 'require' section from your lib to your sample implementation. Change 'yourlibnamespace' to your library namespace and "D:\Code\yourlib\src\" to your local path to your library source.
This way any changes are immediately reflected. However you will not be using or testing your library's composer.json file at all. If you change a requirement in your library .json it will not flow through at all. So it has some big disadvantages, but does do what you want, which is to test your library implementation immediately with the least commands possible.
add your example implementation directly in your library tree (recommended)
Usually you just have src\ and tests\, but many have examples\ where you can find sample implementations. As you develop your application you can contribute to these example implementations. You can do this in a local git/svn repo, and you have the advantage of getting the lib's 'require', plus the namespace automatically. It is the best of all worlds. I recommend this method.
It seems most answers on this thread are not "in the know". I am new to Composer myself, but these answers are misleading. The question could simply be stated as: "How can I develop a composer package".
Yes, you could use a custom repository or upload an unfinished package and update it after every change. That neither is the correct solution or the answer to the question.
It doesn't help that Composer's official documentation doesn't state this upfront, but you can see the heading on the Libraries documentation page:
Every project is a package
This is very important to understand
composer.json:
The previously mentioned page goes on to state:
In order to make that package installable you need to give it a name. You do this by adding the name property in composer.json
{
"name": "acme/hello-world",
"require": {
"monolog/monolog": "1.0.*"
}
}
In this example so far, we have a required package, and now a name. Note the vendor/name format.
So now to autoloading our own files, which is documented on the Basic usage page.
{
"autoload": {
"psr-4": {"Acme\\": "src/"}
}
}
This will autoload the namespaced class files under the src/Acme directory.
On to the fun.
Install/Update
Install or update the package with the command:
composer update
or
php composer.phar update
This will download the required packages and create the autoload.php file
Our project structure should look simular to the following:
src
Acme
Foo.php
vendor
monolog
...
composer.json
Including
Now to test.
Include autoload.php
require_once 'path/to/project/vendor/autoload.php';
Assuming Foo.php looks like the following:
<?php
namespace Acme;
class Foo {
public static function bar(){
return 'baz';
}
}
?>
we can then call this from our script:
echo Acme\Foo::bar(); // baz
Please correct any misleading information I may have stated. This is what seems the be the solution to a popular question.
Maybe adding a custom repository will help you?
https://github.com/composer/composer/blob/master/doc/05-repositories.md
You can set up a local git repository with your library very easily.
Of course if you use composer to manage dependencies you should build your library someplace else and download it to vendor/ via composer coz this is the whole point i guess.
That's my flow of creating and developing a new Composer package locally:
Create a new repository for the package on GitHub (just an example)
Add it to Composer's database (packagist.org)
Add it to your main project via composer require. This is where you start wondering how can you apply hotfixes quickly
Clone it on your local machine somewhere, this is where you develop it
Now to test your local version, add a php require() statement where you load the class files in question. The autoloader won't load the one downloaded via composer but your local one.
When you're done hotfixing, delete/comment out the the require statement to revert back to using the composer version of the package.
Commit all changes, tag the commit and push to GitHub; hook fires to update Composer. Run composer update on your main project, the package gets updated to your local version.
This is still not ideal, but it gets the work done for small to medium packages.
To make developing more efficient I simply symlink the development repository into a directory that has already installed it.
For example, if /Code/project-1 requires a package that's in /Code/package-1, I:
Commit package-1 to GitHub (can even be private).
I then tell project-1 to install it using a custom repository (see other answers for the link to repository configuration).
Once it gets installed, I symlink /Code/project-1/vendor/developer/package-1 to /Code/package-1.
That way, when I make changes in /Code/package-1, it's immediately reflected in /Code/project-1.
My workflow does not completely answer the OP's question but may be helpful for others.
I like to develop a reusable package / lib in a real world project and I do not want to go through git / composer locally.
I also do not like to load the package differently locally compared to production (e.g. through a local require statement or local composer setting).
So what I do is simple: I add the package directly under the vendor directory, either directly or using a symlink.
drawbacks
When using composer update / install, your package may be overwritten. (so I tend to update or add dependencies one by one, during this time).
When not being careful, composer install on the production environment may install a different version. So keep pushing your package and version tags!!
Changing the package's dependencies and loading it in the parent project trough composer update, overwrites the package's folder