I just upgraded to PHP 7.4 and encountered the curly braces problem with a number of third party PHP applications. It was easy enough to upgrade them until I hit MPDF which was installed using Composer.
I've spend a day on it so far and I've finally reached the point where if I run ...
composer.phar require mpdf/mpdf dev-php8-support
Composer says it's upgraded MPDF, but the curly braces error has not been fixed and investigation shows that in actuality, none of the files in the /vendor/mpdf/mdpf folder have changed.
Composer appears to have done nothing.
I've run out of ideas as to how to get this to work.
While the official MPDF page has an installation guide it doesn't even even mention upgrading.
Does anyone have any clues as to what might be going ? ... or perhaps even better - how to just download and replace the PHP files? (which would be infinitely simpler than messing around with an intermediate software package just to copy a few files onto a server)
EDIT: Just to prove that composer isn't actually doing anything I deleted the /vendor/mpdf folder and ran
composer.phar require mpdf/mpdf
again and a new /vendor/mpdf folder wasn't created.
Solution:
Reinstall Composer
Completely Uninstall MPDF
Re-install MPDF
oh and ...
Pray that I never have to upgrade anything via Composer again.
Related
everyone, I've been working on my project, and then I needed to install extra package on laravel, so when I tried so, I got an error, and then I discovered that files in vendor\bin directory are empty, I don't really know why so, but does anybody have any idea how to recover it, or what I have to do?
screen
Delete the composer package lock file, and then a simple
composer install would work.
I have a custom platform that I deploy to projects via composer. My new version is version v3.6.29. It turns out that one of my new dependencies for this project got a random $ character inserted into the middle of the package name (due to my fat fingers) in the composer.json file of the platform, which basically broke it.
I went to the site I wanted to install this new version for and did composer update vendor/pkg-name and it goes through and checks and just says its has nothing to update... but I know for a fact there is an update. So obviously there is some reason it chose not to install the new version...
But why?
You would think composer would be smart enough to think that I might want to know the reason it chose not to update to to the latest compatible version, right? I guess not! But how can I force this in the future?
I tried composer update -vvv vendor/pkg-name and that literally told me nothing new.
I also tried composer why-not and composer prohibits for my package and received no useful information.
The only way I was able to find out what the problem was, was by doing:
rm -rf vendor;
rm -rf composer.lock;
vim composer.json
-- Change version of my platform from "~3.6.0" to the specific version I wanted to install, "3.6.29"
-- Save / Quit Vim
composer install
And then I finally get this output:
Problem 1
- Root composer.json requires vendor/pkg-name 3.6.29 -> satisfiable by vendor/pkg-name[v3.6.29].
- vendor/pkg-name v3.6.29 requires vendor2/pkg$name2 ^2.8 -> could not be found, it looks like its name is invalid, "$" is not allowed in package names.
I mean do you think, maybe, quite possibly, that I might want to know this is the reason that it would not upgrade to the latest version? Maybe not, I guess in a normal scenario the installer might not care about the reason but from my point of view, as the developer of said package that is refusing to install to the latest, I want to know why its skipping it.
My questions is simply this:
When composer refuses to install the version of a package you want, and that you know exists, but is not telling you WHY, how can you FORCE it to explain it's self when it decides to fall back to a version that is "acceptable" to it rather than the optimal version?
I feel like jumping through the hoops I had to jump through to figure out the problem cannot possibly be the best way to accomplish this? What am I missing here?
I was wondering if it is possible to use Composer to install dependencies for a script and then uninstall composer, as it is known to be a big RAM hogger.
Would this work?
Thanks
Once the Composer has downloaded the dependencies, it has nothing to do with the them. They remain in your local directory.
I have not personally experienced the RAM hogging of composer. So no idea about that. As far as my knowledge is concerned, composer downloads the dependencies and stops working until it gets another command!
You can feel free to uninstall it after you've got all libraries set in place.
I am reading/learning about Composer, the application-level package manager for PHP.
In this blog post written by lead dev Jordi Boggiano, he writes:
Composer on the other hand forces you to declare your project
dependencies in a one-stop location (composer.json at the root). You
just checkout the code, install dependencies, and they will sit in the
project directory, not disturbing anything else on the machine.
Another related feature is the composer.lock file that is generated
when you install or update dependencies. It stores the exact version
of every dependency that was used. If you commit it, anyone checking
out the project will be able to install exactly the same versions as
you did when you last updated that file, avoiding issues because of
minor incompatibilities or regressions in different versions of a
dependency.
If I understand Composer properly, when we're talking about packages downloaded/installed by Composer, we are talking about PHP code packages, ie, programming code written in PHP, and not system-level packages, eg, extensions to the PHP runtime installed on the server. So once these PHP code packages have been downloaded and added to a PHP project, I would have thought those packages become part of the PHP application source code, eg to be checked in to whichever version control system is being used for the project. If another developer comes along and checks out the code, why would they need to then "install the packages", as is stated in the blog post? Wouldn't they get a copy of all code packages when they check out the code from source control? This line in the blog post is confusing me, and making me think I don't understand Composer.
Any clarity on this would be greatly appreciated. Thanks.
The dependencies themselves should not be commited to source control. The composer.json and composer.lock files, on the other hand, should. There's various reasons for this, amongst them:
Every time you update the dependency you would have to commit the changes. That kind of tightly couples your code to the dependency, when it should be exactly the other way around.
The packages themselves are already in their own repository with their own history. Why repeat that in your project's history?
Those repositories can be huge, just muddling the waters around your project. Why carry around all that weight?
Instead, having each developer just run composer install (very important: not composer update) whenever they check out the project is much more efficient. Composer will install the dependencies from composer.lock, making sure everyone running the same commit is on the exact same page. The same goes for deploying.
You can read more about this here.
On the other hand, there might be situations where you have to commit your packages to get around a problem, like for example when you know you won't be able to run composer install on your production server (shared hosting)
Normally packages installed via composer don't get checked in to source control, only the code you write and the composer.json and composer.lock files.
This way the repository for your project does not get bloated with code you did not write and possibly don't really care that much about.
Yes its normal after cloning down your repository a developer will need to run the "composer install" command. The composer.lock file will ensure they get the same modules and versions of them you used when creating your project.
Not including the composer modules in your source control also allow you to easily update to the modules to get bug fixes and new features in new versions of them.
I'm using the mPDF library for PHP, but the current release is not compatible with PHP 7. Various issue threads on Github suggest using the current Dev version; but it appears that simply downloading the Zip file excludes important files (including the /vendors/ directory and the autoload.php file.)
The developer seems impatient with people asking this question, and actually told somebody "go ask on StackExchange". So... here I am.
How the heck do I download the entire package from the development branch?
As stated in the comments, the package you are trying to use is being installed through Composer
Install Composer to your machine if you did not do it previously
Unzip file to directory of your choice
Navigate to such directory in command line / terminal
Run composer install