According to this answer, packages listed in composer.json's require-dev section will still be installed when you do
composer install
Since composer install is a normal thing to do as part of a production install, to install all versions specified in the composer.lock file, how do you avoid installing things you only need for development? I'm accustomed to Gemfiles, where specifying something for dev means it is ignored in production, and can't quite wrap my mind around why anyone would ever want to install everything in production.
Aha... I missed the --no-dev flag previously. Apparently you have to specifically tell composer install that it should ignore the require-dev sections. In a way this makes sense, since you more often type composer install on your development laptop, and composer install --no-dev will probably be a part of a deployment script where you don't need to think about it. So the defaults are set up for developer convenience.
Related
Laravel Backpack recommends to install the backpack-devtools via composer, and to exclude them from production by running the composer install command with the --no-dev parameter. This would allow to use the package in the local environment while excluding it from production (https://backpackforlaravel.com/products/devtools).
This works perfectly fine by itself, just when I use a CI, I would run unit tests, and I would not really want to install the backpack-devtools in the temporary CI environment. Yes; one could just add that license key to the secure variables, run the composer install without --no-dev parameter and either ignore the backpack-devtools package or delete it, but I wonder if there is a smarter way of doing it and not include it at all.
There is no way in Composer to install everything but one dependency. So no, I’m afraid you cannot do that.
What you might be able to do, however, is to run “composer remove —dev backpack/devtools” in your CI/CD pipeline, before the “composer install”. That should make it install without it.
I'm working on a project based on PHP7 and Laravel. Unfortunately, there was a problem with dependencies and package versions.
I guessed that the previous developer working on the project started updating packages by calling
composer update
on his local dev environment.
Therefore, a new composer.lock file has been generated and everything has been pushed to the production server - however, the composer update command has not been called on the production...
There is a problem with the incompatibility of the PHP version and other errors in dependencies.
This is a very large project and I wouldn't like to migrate now to higher versions on the production server.
I am currently preparing a development environment and I care about maintaining the maximum compatibility of all package versions with what is on production.
By calling:
composer install
on local environment, I'm receiving a series of errors related to the incompatibility of the package versions.
Is there any way to regenerate / restore composer.json and composer.lock based on what is currently installed on the production server? Unfortunately, at this moment composer.lock on production doesn't completely reflect the current state of actually installed versions.
What is a safe and good way to recreate locally a cloned project from a repository on a production server - and maintain full compatibility of all package versions, the correct form of composer.json and composer.lock?
Thanks in advance for your help!
To run composer update and composer install
You can run with this code
composer install --ignore-platform-reqs
Or for update
composer update --ignore-platform-reqs
I found https://www.wuhaiqiao.com/2020/11/24/329.html
No, there is no way to recreate composer.json file based on what is already installed in /vendor. You can look for /vendor/composer/installed.json file as a reference for installed versions of all packages.
What you need to do in this case is:
Make sure your local environment is exactly the same as your production one. You can fake it if needed in your composer.json too by using platform configuration.
Your composer.lock file is of no use. Get /vendor/composer/installed.json file from your production. Delete your /vendor folder.
Run composer install. Write down all packages that have issues and check provided solutions by Composer.
Start downgrading the versions in your composer.json for packages that have issues based to the solutions provided by Composer. Be sure to look into those packages yourself - developers aren't always very strict with the way they maintain dependencies and versioning of their packages. You can always just take package version from production's /vendor/composer/installed.json and place that specific version in your composer.json.
Repeat steps 3-4 until you can finally generate new composer.lock file. Make sure your composer.json and composer.lock files are tracked by your VCS and fixate the changes.
I have a Laravel App and I want to install require dependencies but I was wondering how does composer know whether to load dev dependencies or production dependencies?
just got confused by this concept so if somebody could clarify this concept for me than that would be of great help.
When you run composer install --dev, composer installs all packages including require-dev. This is the default behaviour, exclusion of the flag would result in the same action.
When you run composer install --no-dev, composer skips the require-dev packages.
Also, composer will not install the require-dev package of a required package unless you specifically ask it to do so
The regular require dependencies are such packages that you will ALWAYS use, meaning that the framework itself (in this case Laravel), your application code and/or other 3rd party code is dependent on such packages. These dependencies are often referred as prod dependencies since you use them in production (because without them, your app wouldn't run)
The require-dev dependencies are "optional", in the sense that your core application logic would run, but you would not be able to run "development" stuff, such as Unit tests (phpunit/phpunit package) and instantiate fake data (fzaninotto/faker).
I hope this helps!
I am developing a PHP website. I have a version on my laptop where I develop everything and my web server which runs the site.
I have found that I can use composer to install PHPUnit only on my laptop and not on my web server using the "require-dev" option Using "require-dev" to install packages in composer
However, this comes with some downsides:
From now on I have to call php composer update --no-dev on the webserver, and if I forget --no-dev then its also installed on the web server
I have to use $ ./vendor/bin/phpunit to call phpunit
I have to do install phpunit for each project on my laptop.
Would't it be much better to just install phpunit on Ubuntu sudo apt-get install phpunit? This way I would not have to worry about using the --no-dev option on the server and I could simply call it by $ phpunit. Am I missing anything important here?
Fast answer is:
You can have a version of phppunit you want in your project and another in another. And --no-dev should be used in production anyway, because you don't want to install all the dev dependencies in Production
if you don't want to call ./vendor/bin/phpunit add a script to your composer.json and then run the tests by composer test or anything you create
Explained in the first one. It really makes sense, especially when you work with some legacy code that works only with some particular versions of php/phpunit etc.
I usually install phpunit, and other tools in the 'require-dev' section, but another entirely reasonable option is to download the phpunit.phar file from the website, and check it in with the rest of your code - updating it manually occasionally.
A local (or global) Composer install will allow for better control of exactly which version is available though, and you can see when it, or your other dependencies are out of date with composer outdated.
As for a production deployment, you should be automating it as much as possible, to make sure that exactly the same thing happens every time. With that, it's just another few characters in your deployment script or other mechanism.
i am on symfony 2.8, and my php version is 5.5.9.
i'm trying to install TINYMCE bundle from composer. I used this command line:
php composer.phar require stfalcon/tinymce-bundle='1.0'
i had this message error:
i tried with v2.0 but same problem.
Have you an idea ?
Thank's a lot for your help.
It would seem that in your composer.json's config section you have platform requirements that conflict with the bundle.
https://getcomposer.org/doc/06-config.md#platform
You could try installing the requirements using the option --ignore-platform-reqs:
composer require stfalcon/tinymce-bundle --ignore-platform-reqs
composer install --ignore-platform-reqs
This will momentarily lift the specified platform requirements. Obviously if they are in place, because they are actually needed - and since they were put there deliberately, at least at some point they were - this might break things on production. So be careful and look at the above option first (updating or removing the platform requirements).
Have you tried either of these two commands:
composer.phar require stfalcon/tinymce-bundle='1.0'
composer require stfalcon/tinymce-bundle='1.0'
I'm not sure if it will make a difference, but it might.