To remove a package using the command "composer remove vendor/vendor" it works, the command dont shows any error. However the package files (classes, etc) are not removed from the folder of the project. Its necessary to remove manually the package fiels that are not removed with the remove command?
Just if you want to remove them from your disk.
If you are running in developer mode, i think that has no problem to let them there, because when you go to deploy your project a new fresh installation script will run with the information of your composer.json, if in your composer.json file don't have any entry with the 'vendor/package' which you want to remove, it will not be installed.
Commonly composer removes any packages that aren't in your composer.json package list fom the vendor folder.
Related
I've just come across the https://github.com/FriendsOfPHP/security-advisories tool which looks a great way to automatically scan for the vulnerabilities that are in that community-contributed database.
It scans a composer.lock file for packages with vulnerabilities. However, it's made me realise that my understanding of Composer is not what it should be!
I have a project that has a composer.json file that requires a single demo/package. That demo package also has requirements, like demo/dep.
The result of running composer install --no-dev is that I have a composer.lock file which includes:
demo/package version 1.0
demo/dep version 1.2
All good so far, and running symfony security:check /path/to/my/project/composer.lock gives me a green light, no vulnerabilities.
However on close inspection of the files now in my vendor dir, I can see there's a vendor/demo/package/composer.lock file, which contains references to demo/dep at version 1.1 - which has a security vulnerability against it.
As I understand, I have the safer 1.2 version installed - so says my project's composer.lock file, but why is a composer.lock file included with the vendor's package?
Does that mean that the dodgy code is installed somewhere, too? Or can I just simply ignore the composer.lock files if there's a composer.lock file in a dir above it or such? composer show does not list the versions in the nested lock file. Or maybe I should ignore composer.lock files if there's no sibling ./vendor/ dir?
Why not simply inspect your folders to find a vulnerable version? If there was any, you should find a vendor folder within that package, that's where that package could have installed stuff from it's own composer.lock
Usually, only the composer.json of a package is evaluated to install dependencies. If there is a lock file within one package's folder, you should ask the maintainer of that package why this is the case, but for installing dependencies on your system, this does not matter.
Side note: writing "usually" refers to the standard model of installations. I've seen some crude stuff where Composer plugins put other rules in place, but this cannot be said for your project without knowing more about the structure.
I am working on the Laravel project, and intend to use Vue.js as its client-side scripting. When I searched the internet, I found that I had to use the npm install command. My question is if I run the order, will it affect the project I'm working on?
For example, in the directory structure or variable section?
It will change only package.json and /node_modules folder (it will download vue.js last version package into this folder) in your root directory. But it won't affect your existing codebase until you don't use them via importing or accessing it. It is like installing a package with composer, but not using it. The downloaded package will stay in /vendor folder and package name in composer.json, composer.lock
I've used following command to remove a package using composer.
composer remove sjparkinson/static-review
Above command removes entry from composer.json file but composer.lock file still contains entry for mentioned library in require section.
What is the proper way to update composer.lock ? Should I update it manually?
Composer does not removing this package, because it is required by another dependency. So even if you don't require it directly, it is still required by your project, so you cannot remove it. You can use composer why some-vendor/some-package command to check what is the reason to keep this package installed:
composer why sjparkinson/static-review
magento/product-community-edition 2.2.4 requires sjparkinson/static-review (~4.1)
If you really want to remove this package, you need to remove magento/product-community-edition too (and every dependency, which depends on this package).
BTW: Editing composer.lock manually is really bad idea, you should never do that.
Time ago, I installed a dependency on a Symfony project. It was the package mograine/calendar-bundle, but now this project doesn't exist anymore and has disappeared from github. It was a fork of another package with some modifications that I need for the project I'm working on.
Of course, I have a copy of the package (under vendor/mograine folder). But, currently I'm unable to run the composer install order, because this package doesn't exist.
And my question is: What can I do to solve this problem? Can I tell composer that this package is installed locally? If so, what should I do to install the package locally? Or I must create a github account and upload all the original files?
If its a normal symfony project, you can simply move it to your src folder resp. "copy past the namespace directories to the src directory" and remove it from the composer.json.
The src folder is autoloaded f.e.
"autoload": {
"psr-0": {
"": "src/"
}
Take care that the namespaces and pathes are correct.
Also see here: moving bundle from vendor to src directory
I use composer to manage packages. But I delete one of files from package (I use composer status -v to check this).
Is it possible to restore changed/deleted files to it base (installed) state via composer (composer install doing nothing in my case) ?
Thanks.
ps. It's look like there no way to restore separate file from repo, after his been changed/deleted. Of course, it's possible to delete entire vendor dir, and reinstall some package totally.
I edit dependant package source code all the time and run into the issue of my local being out of sync with the remove source.
When things get really sideways and nothing works: delete the package providers dir inside the ./vendor (exp: ./vendor/author-name). Then composer will see the package is missing when running composer install. It will re-download the version specified in composer.lock.
If you want the latest version of all the packages when re-installing; composer update is what you want.
I also recommend using -o -vvv to generate the AuoLoader file and provide verbose output.