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.
Related
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 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.
I have a Laravel 4.2 application and it in production environment.
Sometime i have bug fixes or updates for it in the local edition, I want to know how do i move these changes from local to production.
Replacing just the file/class that was changed doesn't work. I tried replacing just the controller file but it doesn't work.
Does Laravel compile the code somewhere that i need to upload to production server, What all do i need to change/upload in production to reflect the changes?
By default, PHP is not a compiled language, so changed and uploaded files will work without any special process. Laravel is just PHP, so it follows the same rules.
However, Laravel uses an autoloader that keeps track of all of your classes. When you add a new class, you need to tell the autoloader that it exists by running:
composer dump-autoload
This will scan the available classes and update the autoloader list.
If the problem persists after you run composer dump-autoload, or if you did not add any new classes, there are three potential problems to consider:
Did you upload the files correctly?
Log onto the production server and look at the timestamp of the uploaded files. Do they match your expectation? Consider opening the files in production to see if they contain your latest changes.
Do you have a caching or compiling system in place?
While PHP is not compiled by default, there are tools available that allow you to compile it, and other tools that allow you to cache the output of the scripts. Ask your server administrator if any of these tools are being used.
Do your changes perform as expected?
Finally, check to see if your changes are in production, but not operating in the way that you expect.
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"
}
Although I'm new to Laravel 4, there has been one question on my mind since day one which I cannot seem to understand, nor find any information on.
My plan is to build an open source web application, which other users will be able to download and use on their own server. Now my current way of working is:
Install Laravel with composer
Add packages to composer than I need for the application
Start coding: editing files directly inside of app/ (global.php, routes, controllers, views, migrations etc).
Keep all of my assets within /public/assets/
This works fine for me, and I have no problems with it. However the question is:
How will I deploy the application to users if I build it this way? If they install Laravel via composer, all of the files within /app will be default (obviously), so how would I go about getting my edited + custom files into their install of Laravel?
Do I have to build the whole application as part of my own bundle? Or is there some kind of way composer can pacakge what I've done to solve this problem I can see happening?
I'm just throwing words out, if someone could explain and point me in the right direction that would be great.
Thanks.
You can just chuck all your files on github. You dont need to include composer. People can download composer and run it from the install directory (or if they have it globally run it from there)
If you run a composer install with laravel 4 only, it will download all fresh. In your case you just have all the library's in place already. So for future updates you as a developer can easilly upgrade to a newer version. The "users" can simply say "git pull" to update their instance. You still need composer to do your initial install (db seed, post install steps etc)
At least that is my point of view. Just look at a simple laravel 4 bootstrap example https://github.com/andrew13/Laravel-4-Bootstrap-Starter-Site it also holds all the files.