I am working on laravel 5.1 project. I have updated few files for customization e.g. vendor/laravel/framework/src/Illuminate/Foundation/Auth/AuthenticatesUsers.php file. It needed to install new package so I had modified composer.json and run command 'composer update' and package was installed but all the code I had updated in AuthenticatesUsers.php file was replaced with original.
How to prevent this over-writing while updating composer?
You are not supposed to edit files in the vendor folder if you also want to use Composer to easily update your dependencies. Editing files of external packages effectively means you are forking that project and maintain it yourself. This either means you only apply your change once and then stop all further development, or you constantly have to check for updates of the original package and merge their changes with your changes.
I am pretty sure there are ways to solve the underlying problem with adding changes to existing files, but your current question suffers from the XY problem - you want to add a change to Laravel but don't know how to do properly, find that editing may solve the problem, but now need to prevent overwriting that file, and ask about preventing that overwriting - instead of asking how to add change to Laravel classes.
A nice and clean solution would be to fork the repository and add it to packagist. Then simply change the composer dependency with your version of improved (so to speak) laravel's source code.
Related
I've got a pretty simple repository made up of a frontend folder in which I have a react app, and a backend folder that is mostly empty for now.
Every few minutes, regardless of whether or not I make any changes to any files, some node_modules file will pop up in GitHub desktop showing a difference.
screenshot of my github desktop
Do I need to add node_modules to my .gitignore file?
This didn't happen before, I don't know what happened to trigger this. I add the changes because I assume it's an important node_modules update but then it happens again a few minutes later.
I'd like to understand why this is happening and how I can prevent it from happening as it makes my commit history impossible to read.
Simplest solution would be to gitignore node modules like so...
/node_modules
Unless you have a specific reason to track changes to npm?
It's usually better to install fresh packages via npm install when setting up on a different enviroment/device.
In my composer.json file I like to list all compatible versions of the (example) package x/y as possible in the require section. Typically that would look like "x/y": "8-10". If I execute composer install, composer of course installs the newest available version of x/y which is 10.x and that is fine, almost always. But sometimes I want to install version 8 of x/y just to check that execution of my application is still possible with version 8.
Another scenario is when a client reports a bug and has version 2.10.4 of some example/dependency whereas the newest would be 2.14.2. The example/dependency is not required by my application directly but transitively by x/y. So I just for a moment want to install my whole dependency tree with version 2.10.4 of example/dependency to debug it with that version of the library.
Of course a temporary modification of the composer.json so that it requires these exact versions would work but that approach seems unnatural, complex, and implies the risk of accidentally committing the modified composer.json to version control and thereby creating a huge mess.
I thought about modifying the composer.lock because accidentally committing a modified version of that wouldn't really cause a problem. But is it okay/recommended to modify the composer.lock file for such purposes?
Ideally I would want a command line argument that fixes some library to some version just for one execution of the composer install command without modifying composer.json.
Since install is meant to read from a lockfile, this option wouldn't make sense for the command.
But for update (and if there is no lockfile, install behaves as update), there is the --prefer-lowest flag (docs).
There is also the option to downgrade a specific package without affecting your composer.json file, by running something like:
composer update --with vendor/package:2.0.1
Mind you, any of these options will modify your lockfile, so after testing you would probably need to git restore composer.lock to go back to the original state.
Commiting a lockfile for a project by mistake should be a biggish issue. Since applications are usually built/deployed by reading the lockfile, a lockfile in an inconsistent state could break things in unexpected places.
But warding of commiting and pushing changes by mistake seems to be excessive, IMO. Developers can make changes to any file, and if they commit those "by mistake", things can break all around.
Expecting a basic "I should look what's changed before staging and commiting" seems a very low bar to me.
I'm following the installation docs for Backpack 4.1 for Laravel. The backpack:install Artisan command adds front-end assets to the /public/packages directory of my project. Usually, front-end package managers (NPM, Yarn, Bower, etc.) recommend not to add the actual package contents to a project's repository, and instead add a dependency lockfile that can be re-installed by a CI/CD pipeline. Backpack does this differently, as it pulls the front-end dependencies directly and there was no mention if one needs to add /public/packages to source control. Should I add these package assets to source control, or should I execute php artisan backpack:install in the CI/CD process instead?
Yes - you should include the public/packages directory in your source control. That’s what Backpack assumes you’ll do.
However, if you would rather NOT do that, you can create an alias to the directory in the package. You can find instructions on how to do that here, as method 3 - https://backpackforlaravel.com/articles/tips-and-tricks/once-in-a-while-re-publish-backpack-s-css-and-js-assets
There are several reasons why you might want to do commit the public assets to the source control:
You may not have write access to your production file system.
You may be deploying to more than one server, and want to avoid duplication of work.
You may be doing frequent deploys that do not include asset changes.
Generally, I think it is a good idea to put precompiled assets into source control unless you have a specific reason not to do so.
I am working on a Laravel project and it's working fine. But
Recently I have updated Composer by composer update and Composer updated successfully.
Then I have removed unnecessary packges from the vendor folder. I have also removed paragonie folder from vendor, which is unwanted for me.
This gave me following error.
Fatal error: require(): Failed opening required '/var/www/laravel/vendor/paragonie/random_compat/lib/random.php' (include_path='.:/usr/share/php:/usr/share/pear') in /var/www/laravel/vendor/composer/autoload_real.php on line 54`
I have added this folder and working fine.
Any one can help me to figure out what is purpose of paragonie folder.
Why it is included?
Composer manages every package inside the vendor/ folder. You simply can't remove any folder from vendor/ without breaking something. Don't do this!
If you want to remove packages from your project then edit your composer.json and perform a composer install.
There might be some packages in your vendor folder that are not required from your composer.json. This is because ever package can have it's own requirements. If you delete one of these required packages you break it.
There is generally NO necessity to remove anything from vendor!
Note: composer update does NOT update Composer itself. It updates every package of your project! To update Composer itself use composer self-update.
I really recommend you to read the composer docs or some tutorial on how composer works for a better understanding of composer.
Don't manually edit composer.json, or the file-structure of the vendors folder. The vendors folder contains the dependencies and their dependencies.
The most important part about this is that you should not EVER edit a project dependency within a project. The second you do, you have broken future updates, This is a terrible thing.
If you feel this is not possible because a library needs changes, I'd suggest taking a breath.
Most libraries have some built-in configuration options, or methods of modifying the library. If they don't then maybe contribute some, or fork the library.
You can absolutely make changes to any library that has a permissive license towards source code modifications, that is why open-source code exists, but you need to do this in the right way.
You can possibly improve the code by forking using source control, which will also allow you to submit a pull-request(PR) to the package maintainers.
The benefit of trying this is that IF the package maintainers decide to accept your changes, you will be up-to-date with all of their future updates, even if you do not have time to maintain your changes, someone will probably pick them up and make their changes.
IF your PR is not accepted; I would strongly consider revisiting your initial assumptions so that you can be sure the decisions you are making are the only way, or the most beneficial way forward. Either way; it won't matter, as you can keep your fork as the version you pull from in future and either add it to packagist (only if you are really more people will benefit from it); or telling composer to pull directly from your repository (it does have to be on the internet AFAIK).
If you have to fork, you will need to ensure you can maintain the dependency, and this is accepted within your organisation. If it's you then in future, you can manually update from time-to-time from the original source library; to ensure you still enjoy the benefits of the core library, whilst keeping your changes.
THIS IS THE DIFFERENCE BETWEEN HIGH-SCHOOL CODING AND PROFESSIONAL DEVELOPMENT.
sorry for shouting / exclaiming, but this needs to be put out there more, possibly in 100ft letters somewhere.
Resolving this problem folowing these steps:
go to your project from terminal (CLI)
cd vendor
svn add paragonie
svn commit -m ""
And if another file is missing do the same thing.
For me it works 100%.
Good luck.
I want to change the floder for additional installed package.How to change the floder path for additional installed packages.
Laravel is framework that depends on many other packages that has been built by the best in the PHP world and makes use of a dependency management tool called composer.
For Laravel to work her magic, she needs the help of composer to download all those codes that has gone through the test of time to assist her. composer would then place all of these codes into a folder specifically tailored for them which is the /vendor folder.
It seems that you need the power of some other codes to help you in your project. If that's the case, you might want to check out composer first for some basics before starting a new Laravel project.
You might want to check this video on https://laracasts.com to get a bigger picture as to how all of these things piece together.
Update
If you need to change the /vendor directory, you can simply change them in your composer.json.
"config": {
"vendor-dir": "new-vendor-dir-name"
}