I'm working with multiple projects, each one separated from the others in my server. So my problem is that I have a Core project that have all the functions I need, and in Laravel projects it's annoying to copy/paste everything every time. I was thinking to create a package and install it in all my Laravel projects via composer, but it bothers me the fact that every time I want to add a feature or perform a minor bug fix, I will have to do a composer update in every project (I have more than 20 actually).
I just came up with some ideas, let me know what do you think about it and if you will use some different idea:
Create a Model/Class that includes my main php core library directly from the server (Remember that I have all the projects in the same server). I will just need to call the Model/class and it will import all the functions. I will just need to keep updated the main library code every time I perform a minor bug fix or any new implementation.
Create a package where inside will have all code I could need to use in all projects (main library). This would be perfect, since I want just use the composer install command get the package installed in my project. I'm not concerned at all with this solution, because I have more than 20 diferent projects and I will need to do more than 20 composer update every time I perform a minor bug fix or new implementation.
The last one is to do a generic composer where it contains all the packages I would need (almost all the projects use the same composer.json) and create a symlink between all the projects. I will install the packages in one folder and keep that updated everytime I perform some new task, and the symlink will keep the folders updated in every project.
What do you think about that options? I think I will go for the 3rd one, but wanna know your opinions or if you have the same problem and works with other solutions.
Or you could create a bash script that runs composer update for all of your projects.
#!/bin/bash
cd /var/www/website.com && composer update package/name
cd /var/www/website2.com && composer update package/name
cd /var/www/website3.com && composer update package/name
Related
I have an app which must work with a specific package in various versions.
I'd like to automatically run local tests against different versions of the package.
How is it done?
I can think of a manual way:
change composer.json
run composer update
run tests
repeat with another version
Update:
As mentioned here, I can just pull another version on top of an existing composer.json:
composer require vendor/package:$(MY_PACKAGE_VERSION)
run tests
pull another version
But one must be careful because you are messing with a working copy of the app. As ob-ivan suggested to clone the app in another place, pull new version and perform tests over there.
Inspired by this question, I have developed a utility just for that purpose.
Introducing DiversiTest: https://github.com/ob-ivan/diversitest
Its primary advantage over running tests in a CI server is that it allows you to test your work in progress before you commit, or even before you code --- for example, if you don't want to make an explicit commit after creating red tests in your TTD process.
How to use
Install by composer require ob-ivan/diversitest
Add a configuration file like follows:
# diversitest.yaml
package_manager: 'composer require $package $version'
test_runner: 'vendor/bin/phpunit'
packages:
illuminate/support:
- 5.4.*
- 5.5.*
And run with:
vendor/bin/diversitest
This copies your working directory to a temporary folder and loops into installing dependencies versions and running tests with commands provided by config.
Note that if you list several packages each with a list of versions, it will go through a cartesian product of all supplied package:version pairs.
The utility is still at development stage, feature requests and bug reports are welcome on GitHub issues page.
I am building a small app with some dependencies and my back-end is in PHP with composer and I use many dependencies.
I used to keep the project up-to-date but sometimes, composer update is just to long!
Anyone have some good tips to help me updating my dependencies? any automated service that can run them for me without breaking my code?
I built Dependabot to do exactly this. Every morning it will check with packagist whether there are any new versions, and if there are it will create a pull request to update you to the latest and greatest.
The core of the app is open source here and it's relatively popular with Ruby and JavaScript programmers. The PHP beta is fully functional, and I'm looking for more people to give it a try!
I use prestissimo for a much faster composer update/install process.
It's a composer plugin aka composer global require hirak/prestissimo
and you are done.
It downloads all ur packages simultaneously and installs them!
This will make composer insanely fast.
Benchmark on a Laravel install without prestissimo 288s =>
with prestissimo 26s!!!
For automating ur Process you could set up a cronjob and let it run a bash script with something like this inside:
Filename in example = composer_update.sh. Content:
#!/bin/bash
composer update --no-progress --profile --prefer-stable
For not breaking ur code I recommend setting a minimum stability in ur composer.json
The cronjob for updating once a month could look like this
*/0 0 1 * * /PROJECT_ROOT/composer_update.sh >> update.log
This article might further help you with cron.
Hope I could help you.
I heard a currently work in progress project wanted to solve this issue.
They link to your github account (you must have one in order for this to work) they want to keep your libraries up-to-date if you're using composer, npm or gem I think.
The thing is, they create a pull-request showing you what will be updated and show you the changelog if there is one for the update.
Take a look at upgator.io
I have to update CakePHP from current, outdated version (2.7.7) to latest on 2 branch, because of PHP7 support.
While I've done numerous framework upgrades before, I found book.cakephp.org a more than a cryptic about key things which I ask here:
can it be done by replacing directoris
which directories are intended to be replaced (never edit dirs, like system in Codeigniter)
which directories are partially replaced if any
is there SQL commands that should be run?
is there other commands that should be run?
Any clue is appreciated, but 2 and 3 are of most value I guess. Thanks in advance.
Depending on how you've installed CakePHP, you either use composer to update the CakePHP core dependency:
$ composer update
or require a specific constraint/version if your current constraint doesn't allow upgrading:
$ composer require cakephp/cakephp:^2.10.3
If you're not using composer (I'd suggest to switch to using it), then you download the latest release package manually, and completely replace the /lib/Cake directory. With respect to the core, the upgrade is then complete.
Then read the migration guides to figure the possible changes that you have to apply to your application code or database schemas, and also compare the "application template" changes (/app/) to your local application and apply changes in case necessary. After this, run your test suite to ensure that everything works as expected.
With that being said, the upgrade from 2.7 to the latest 2.10 should be pretty easy, as it is said to be fully API compatible.
I recommend you to use composer to manage your framework and extensions.
With composer installed, it would be much easier to update. If you decide to use composer, let me know if you need any more help by installation, setup or update.
I recently started a project using composer for the first time, and I just deployed it to Q&A (demo), with git I used to just do a git pull and update the Q&A environment, but now with composer update only the dependencies get updated.
My question is, what is the SOP(standard operating procedure) for updating the core project, do I still use git, or is there a way to do it with composer?
Or am I completely doing this wrong, and should be working out of the vendors folder?
The point of Composer is that you don't need to version control the dependencies which means anything that ends up in vendor/.
The project has a composer.json and composer.lock. These are within git's control so it knows the packages and versions to use. However, the vendor/ directory should be ignored, with .gitignore. If you don't already have that set up simply add this line:
/vendor/*
You version control your other files as normal.
So the operating procedure is to use git and normal. Followed by composer update.
The advantage of this setup is that git doesn't have to bother managing potentially thousands of files (inside vendor/) that will never normally change. The only circumstance under which they'd change is if you want to start using a different version of a package, or adding new ones. Well, all of those packages/versions are defined in your composer.json (which git is monitoring for changes). All you need to do is run composer update and it will update everything in your vendor/ directory to the "right" version.
That's one of the advantages of using Composer - all developers can have a "list" of the correct packages/versions, without the need to version control all of the files in them.
Edit as per the comments below:
Note composer update should only be run in development. Use composer install when deploying to QA or production. This will install the exact versions referenced by your composer.lock file.
You keep using git for your project and composer for 3rd party libs.
I have a large web app in PHP (link in my profile), and that's how I've been doing it, and it works good.
When I have new production-ready code and it's ready to be released, I do:
git fetch && git pull
And when I want to update composer, I do:
composer -o update
I don't know if you're familiar with -o flag - it generates static autoloading maps, which makes your project load classes faster. More info here.
I'm already half way done with a project in Symfony2.
I need to install a couple of new vendor bundles using composer.
I already have everything (minus logs, cache and parameters.yml) in version control (including the vendor folder).
Problem is when using composer update, it deletes the .svn folders in the vendor folders that where updated. So it's basically impossible to commit now (gives me not a working copy error).
Additional information: I'm working locally and committing to a dev server and then once approved an application server. Therefore it has to be perfect (cannot just run php composer install or php composer update on the dev/application server after commit).
I also tried exporting everything and copying and pasting them back into the repo but that also didn't work (index page broke locally).
Regarding to vendor versioning the best way is not version vendors at all.
The only things you need to version are composer.json and composer.lock. This may cause a problem with vendors which doesn't have stable versions or with that for which you need not stable one (eg. master with particular commit).
As a solution you should create your own (private) vendor repository (let's say your own packagist). Composer has a tool for that, which is called Satis.
https://github.com/composer/satis
So my suggestion would be:
Create a private repository with Satis. You place every package you need in satis.json and whenever you need to update a version of vendor, or add new one, you only modify satis.json and rebuild repository.
In your project's composer.json you set your new private repository as the only repository and set option: packagist to false.
Now, every time you run composer install it will use only your private repository, so it's fast and you always sure that every environemnt has the same versions
-
I was in similar situation two years ago.
The hard lesson I learned was never to edit files within vendor. At first I totally rejected using composer and manually cloned everything I needed. Later on, I decided to fork projects I needed to edit and referenced my forks instead.
Composer supports private GitHub repos - you don't need to register it to Packagist in order to work.
You should not keep your vendor directory in your version control. This is how it is done in Symfony Standard Edition and you should follow this. Running composer install command should be a part of your deployment process
Including vendor packages in your codebase is not recommended, so if you need to maintain the same version of the packages you use on your local machine, the best way is to keep composer.lock in the VCS and running only composer install on other environments.
Additionally, if you want the prod deployment to be instant, without depending on the composer process, you could run composer install on the dev server, and once it's validated you can make your prod deployment script copy the vendor folder from the dev env.