I'm developing an application that consists of several modules/packages which i also want to offer as standalone packages. I know how to create composer packages but i'm not exactly sure on the best way to do the actual development and need your help on this.
One way would be installing the packages with composer but that would mean that, for each change, i would have to commit and then do a composer update on my app, just to able to test it. Not very practical.
Another way would be to have them included in my app, although having the package internal structure. That would work fine for developing but would pose a problem on publishing individual packages since all the code would belong to the same repository.
I think a good example on this is the way modern frameworks, like Laravel, are available. They have the whole code available in a repository but, at the same time, have each individual component available standalone.
What's the best way (in your opinion) to accomplish this?
Thanks in advance.
Symfony2 uses Git subtree split. That is, a single development repository which is split into multiple repositories later.
Don't make any mistake about it though, the code is the same, but they "are different" repositories, and the procedure to maintaining them is rather long winded.
http://www.craftitonline.com/2012/03/git-subtree-split-this-is-what-symfony2-does-every-night-to-set-standalone-components/
Related
So I am working on two different applications using laravel and both of them need a lot of the migrations, seeds, models, controllers, routes and so on similar to each other. In fact in most cases, they are absolutely same. What is the best solution to avoid redundancy in such a case.
The best solution I came up with was to extract a package and then use that package in both the applications but there are drawbacks. Every time I need to add a new feature which needs to be added to both of the laravel application, the package needs to updated. Once the package is updated, the main applications are updated. Sometimes small syntactical changes make me change something in the package and then update the packages again to see if it is working. But soon it becomes painful like this.
I have also tried using symlinks in composer file so that the package gets updated as I am working inside an application which uses them, but I still have to update the other application. Moreover, I still have to remove the symlinks before I push because the symlinks break in CI. They need the direct cloud URL for the repository.
Has anyone else gone into a similar problem with laravel and has an idea of how to resolve it? Or the best solution regarding the same.
While developing a Symfony2 project, I often come across bugs in third party bundles. Most of the time the bugs are subtle but hard to find. For example this week alone I have found three bugs where a value was tested using a simple if ( $value ) construct but required the use of ( $value !== null) or ( $value !== false ).
Without having sufficient permissions on the relevant github pages for the projects in question, the best I can do is push a pull request. It usually takes quite some time for the request to be merged. In the mean time, especially when using the master version, other pull requests are merged which in turn leads composer to update. When that happens, any local bug fixes will revert back to the original code.
Is there any method to handle this situation?
Ideally, I would like the third party bundle to update but have my modifications persist. Until the pull request is merged of course.
There is a project that allows you to apply patches after downloading packages with composer. It is created to be used with the Drupal project but I believe it should work with your own patches just as well.
https://github.com/jpstacey/composer-patcher
Otherwise, you could fork the project, make you improvements, submit a pull request and in the mean time use your own forked repository in composer. See [this answer][https://stackoverflow.com/a/14637668/3492835) for a detailed description of how to achieve that.
Edit:
The stars say it is about to be 2016 now, and a few things have changed.
jpstacey/composer-patcher is considered deprecated in favour of the netresearch/composer-patches-plugin project. This is a Composer plugin which does basically the same, but it is able to apply local patches as well.
Composer does not support this functionality out of the box. The reason is simple, one should not work with the development versions of other libraries. But fear not, you can easily work around this by forking the projects on GitHub. Of course this means a lot of overhead, but it is the best solution I can think of with which you can tackle this problem.
Note that this approach has several advantages over the patch approach:
You can directly create your pull request from your fork.
The git merge process will identify any conflicts.
A script to automate this process is easy:
#!/bin/sh
git fetch upstream
git checkout master
git merge upstream/master
You could create a Composer post update/install script which executes these command in each projects local directory if it is one of your forks. (I leave this implementation part to the reader. But one would need to create the repository locally first, since Composer only downloads the latest files without an repository data. This might add huge .git folders to a project since some projects are, well, huge.)
We have a huge code-base (I mean huge, about 2M+ lines) in PHP. I would like to know how you guys managed to integrate composer in this kind of situation.
Specially when the code cannot be decoupled in little projects (Right now) because of the complexity (Even mixed with legacy code) and it's being hold in the same SVN repository.
Why should I be confident in the quality of the composer/packagist libraries?
What happens if packagist goes down?
What should I do if my vendor repository goes down (Github/Bitbucket/Whatever)?
What happens if some of my vendors decide to delete their library?
What if they've been hacked and set the next version tag empty?
I know that this possible problems could be over-passed in one way or another. But the fact that the life of a lot people could be depending on this makes me feel a bit crazy with this kind of decision.
What do you think? What are my best options?
For the first point - if you have legacy, 2M+ tighthly-coupled codebase, common open source projects quality shouldn't bother you ;).
For the rest - you can use staging to build your project together with dependencies and then build a full package there (by that I mean all the dependencies downloaded and bundles). Of course you will still be dependent on external packages on your development cycle, but not in deployment/production. Whenever package goes down, you have time and possibility to replace it.
Composer is a really great tool for bundling yor project together with dependencies, so it's both the answer to question "how to use external dependencies" and also to "how to be independent from them", you only need to specify the point, at which you want to bring this independency into your project.
I think that you should develop with external dependencies in mind, lowering your code base as much as possible and not put these problems on your devs shoulders, they want to use code, libraries, play with tiem... then, somewhere in your deployment process, bundle it all together (staging is a good place). Even if your dependencies will disappear and you will have to spend your development time to replace them:
It will probably still cost you less than handling all on your own.
I have been making a CMS as a project for a little while now, and am currently working on the plugin management section. Instead of building my own repository & update manager, I've been toying with the idea to use composer instead. The issue is I want the admins on the site to be able to add/remove plugins at will.
So I was thinking, how bad of an idea would it be to build a front-end which runs composer? Composer is just PHP after all, it's meant to be run on production environments (granted with a composer.lock file though), and it'd resolve all of my repository, update, and dependency needs.
I knocked out a quick test script, I built and passed in a custom configuration file (instead of composer.json, the installed plugins list is stored in the database), and everything seems to be working fine. But I can't shake the feeling of this being a bad idea.
Does anyone have experience with this, and whether or not it is a good or bad idea?
Using Composer as an embedded dependency manager with a front end is actually a very valid use case for it. Here are some links with information, as well as a project meant specifically to help with embedding composer into an application.
https://github.com/dflydev/dflydev-embedded-composer
https://sculpin.io/documentation/embedded-composer
http://srcmvn.com/blog/2013/05/23/symfony-live-2013-portland-embedded-composer
Some background first
Our company, a small startup with only four developers, is starting the refactoring of our products into reusable modules to simplify the development process, increase productivity and, along the way, we would like to introduce unit tests where fits.
As usual on a small startup, we can't afford wasting too much development time but, as we see, this is extremely important for the success of our business on a medium and long term.
Currently, we have two end-user products. Both are Laravel (PHP) applications built on top of our own internal business layer, mainly composed of webservices, restful apis and a huge database.
This business layer provides most of the data for these products, but each of them makes completely different use of it. We plan to build other products on the near future besides maintaining and improving those two that are almost finished.
For that to happen, we intend to abstract the common logic of those (and the future) products into reusable and decoupled modules. The obvious choice seems to be Composer, even with our little knowledge about it.
Now to the real question
I would like to ask other opinions on how to develop internal packages on a test driven fashion. Should each module be a composer package with it's own unit tests and requiring it's dependencies, or should we build a single package with each module namespaced?
To clarify a bit, we would like to have, for instance, a CurlWrapper module and that would be required on our InternalWebserviceAPI module (and a few others).
I personally like the idea of having completely separate packages for each module and declaring dependencies on composer.json, which would mentally enforce decoupling and would allow us to publish some of those packages as opensource someday. It also may simplify breaking changes on those modules because we could freeze it's version on the dependents that will need to be updated.
Although, I also think this separation may add a lot of complexity and may be harder to maintain and test, since each module would need to be a project on it's own and we don't have all that man power to keep track of so many small projects.
Is really Composer the ideal solution for our problem? If so, which would recommend: single package or multiple packages?
Edit 1:
I would like to point out that most of these modules are going to be:
Libraries (ie obtaining an ID from an youtube URL or converting dates to "x seconds ago")
Wrappers (like a chainable CURL wrapper)
Facades (of our multiple webservices, those require the other two kinds)
Yes, composer is the way to go and I recommend you to use single packages.
You don't know when you need these modules. It is better to create many single packages and be able to include them all (or a single one), than creating big packages and need to put more time in breaking a package in multiple ones when you need some classes from it.
For instance, see the Symfony2 project. That is a lot of components which are all required for the full-stack Symfony2 framework, but you can also use some components in your own project (like Drupal8 is doing). Moreover, Symfony2 gets more and more packages, it seems so usefull to have small packages that people put time in breaking some big packages in pieces.
An alternative to using single packages: use separate composer.json files for each subproject.
This has the benefit of letting you keep all of your libraries in the same repository. As you refactor the code, you can also partition autoload and dependencies by sub-library.
If you get to the point that you want to spin the library off into its own versioned package, you could go the final step and check it into its own repository.