I have the problem that during a Shopware 6 update (e.g. 6.4.18.0 -> 6.4.19.0) the root composer.json changes.
Since it is possible to install plugins via composer require all the required plugins and installed plugins are missing after the update.
How do i handle that? What is the best-practice for this case?
How did you install shopware in the first place? When you install shopware over the webinstaller, then you should update over that way as well and changes in the composer.json will be overwritten by an update so you have to add those changes manually again.
If you set up your project using composer you should update by pulling the latest changes and if you have manual changes in the composer.json, those changes will be merged via git.
With the new symfony flex setup all of this should not be necessary anymore and your root composer.json should not be touched anymore during updates. The flex setup will be the default setup starting with 6.5 and also the webupdater will switch the existing installations to this setup.
You can follow this guide on how to switch to the new setup.
Related
I am using Neos CMS for my website. Now I am trying to update the CMS via composer update. Inside my project I installed a package that is now abandoned. That resulted in a failed update because the composer.json inside the package does not require the newer version of the CMS. Basically I just need a way to completely ignore that package while composer is updating. --no-dev did not work. That resulted in: Running update with --no-dev does not mean require-dev is ignored, it just means the packages will not be installed. If dev requirements are blocking the update you have to resolve those problems. Would be great if someone has an idea.
If the source of the abandoned package is still available, you may create a fork of it, change the requirement settings and then include your fork like described in How to require a fork with composer?
A much better way would be to exchange the package with something else which is still maintained. If you rely on the functionality of this package in your project(s), it may be worth to maintain an updated fork of it on your own.
I'm installing Drupal 8.x via composer downloading any dependencies from the Internet and all works fine.
In this way however there is no guarantee that the same versions of dependencies will be available every time I install. One server might have an updated version of a module than another Drupal server if I install in different time. I would like to prevent against this by using a local mirror.
Is it possible to provide a local mirror to composer and how?
Any example / reference / suggestions?
If you are worried about the versions, then the best way would be to define the exact versions you want in your composer.json if need. But apart from that, after you install your dependencies, you have a composer.lock file that has the exact versions in it. This file is committed to your version control and used as the base to install: this way you always get the same versions (until you update of course).
A separate problem might be that there is no internet, or the specific versions are not available for some reason. This shouldn't happen (often), but in that case you should pick this up before you 'release'.
The best practice would be to build (finding out if you have all packages available) and then release. You could even create a separate build server that creates your project including the vendor dir, and push from there. The fact that your vendor dir is not in your version control does not mean you have to get all dependencies on your production server each time
This means you have a local copy of your vendor, which is not a local mirror of composer per se, but close enough for comfort.
I'm coding a Laravel Package, and a very annoying thing is my workflow is that when I want to try my plugin in a new Laravel installation, ( I install it with composer require "myplugin/myPlugin" ), it is mandatory to tag in github a version, so packagist can get the latest change.
This is annoying because sometimes, even for a small change, I must create a new version, and I would like to follow Semver standart.
What am I doing wrong?
We have composite project with many custom and 3rd party libraries.
We are looking for a way to update most of the sub project with composer update..
but to be safe, we need to lock down all the sub dependencies to the currently installed version.
I had no problems with tagged versions, but "dev-master" gives me trouble
can a Lock a dependencies "some/fu" : "dev-master"
(with current version 0.1) to stay as it is, and never update to 0.2 ?
The problem is that dev-master is a moving target. So the meaning of dev-master can change at any time.
Let's say that it represents the latest 1.0 development version. At some point the author of said library starts working on the 1.1 release, so they branch off a 1.0 branch, and dev-master becomes automatically the latest 1.1 dev version.
Technically the dev-master has no version it is a version and it represents the most current development state of the master branch.
If you have control over the source repository which you want to require you could make use of a branch alias.
Or you can update only specific packages like composer update vendor/package1 vendor/package2 or to shorten it specific vendors composer update vendor/* instead of a full composer update. As far as I know there is no possibility to exclude specific packages from update yet.
In addition to #Peh answer:
Yes, using dev-master is a bad practice. But if it is a really necessary you can pick up certain commit "symfony/finder": "dev-master#2633721877cae79ad461f3ca06f3f77fb4fce02e"
What scenario does lead to problems with master branch? when do you want execute composer update?
Ive been reading a few articles on the net about package development but cant quite wrap my head around the basic setup. Ive written jQuery plugins with releases and published to Bower in the passed so maybe im just not understanding the difference with Laravel.
With jQuery plugin dev I would just exclude my dev required dependancies through bower.json to prevent a person pulling in my dependancies. It seems that with Laravel u create an un-tracked Laravel framework folder and put your package into the vendor folder and track only that with Git? So basically the Laravel project sitting outside of my vendor package is just some files on my PC? Surely I would want to track which version of Laravel the package was developed on?
OR should I create a "base" Laravel repository and create another repository inside the vendor folder so make sure I know which Laravel the package was built on?
Documentation and tutorials are very vague...
Your question looks a little bit confuse. I develop packages for Laravel and the following is a regular way:
Laravel manage its dependencias via composer, take a look into composer.json to get a clue how similiar is with bower.
In order to get yout package compatible with laravel's core you need to implement some interfaces in your package. This package also can manage dependencies via composer.
A package can be created as a repository in different version controls, like Github, BitBucket, Packagist, Cartalyst, private packages repositories, etc. By default laravel pull packages from Packagist, but into composer.json file you can specify another reposository as needed.
When you trigger composer update (this is an equivalent as bower update), this dependencies manager will pull all the packages and download them automatically in vendor/ directory.
How to code your package while testing with laravel? some people do the following, including me:
Install a laravel instance just for package development purpose.
Create a new project (your package project) inside of vendor/project-name following lavavel's package requirements.
Keep working your package from this project location. By this way the changes are reflecting instantly in laravel installation.
Don't forget to commit and push