I need to upgrade Laravel from version 7 to 10 but there are many conflicts due to long time of not using Composer and editing the composer files manually.
I get all sorts of errors such as errors due to "partial update" or "fixed versions in composer.lock" .. etc.
Can I just delete composer.lock and do composer install with the correct packages of Laravel 10? Or that is not a good idea?
It is not recommended to delete the composer.lock file and do a fresh composer install as this can cause compatibility issues with your dependencies. Instead, you should follow the Laravel upgrade guide for each version incrementally until you reach version 10. This will ensure that all dependencies are updated correctly and any breaking changes are addressed along the way.
Here are the general steps to follow:
Backup your project files and database.
Update your composer.json file to require the new version of Laravel.
Run composer update to update your dependencies.
Follow the Laravel upgrade guide for the version you are upgrading to. This may involve updating configuration files, routes, and other code changes.
Test your application thoroughly to ensure everything is working as expected.
Repeat steps 3-5 for each version increment until you reach version 10.
Here is an example of updating from Laravel 7 to 8:
# Update composer.json to require Laravel 8
"require": {
"php": "^7.3|^8.0",
"laravel/framework": "^8.0",
...
}
# Run composer update
composer update
# Follow the Laravel 8 upgrade guide
https://laravel.com/docs/8.x/upgrade
# Test your application thoroughly
Repeat these steps for each version increment until you reach version 10.
@ligonsker What do you mean, “editing the Composer files manually”? Why have a dependency management system like Composer in place if you’re not actually going to use it?
@martinbean Yes but we had the network closed for over a year due to security issues so some developers came up with weird solutions to make things work (We did not really have composer for a long time and had to somehow add packages to the existing project)
Besides the packages required by laravel, don't use outside packages. There are a couple of exceptions of course for known safe (developer has known integrity) packages.
Just me, but I don't trust all the packages from Github.
@Ligonsker So your network was locked down because someone didn’t trust a dependency manager to install dependencies, so you just “manually” installed the dependencies any way, thus making the process of “locking down the network” completely moot when the code was added to projects any way…?
@martinbean They tried to manually install each package (and its dependencies) one-by-one (after manually checking and scanning each package) 😅 then tried to add that to the project. that didn't work too well
@jlrdw thanks. Using only a few and all widely used (And only after scanned against all known vulnerabilities databases such as the composer DB and the US govt. CVE DB - it will automatically be blocked if any small thing is detected also).
Do you think the following will work to jump from Laravel 7 to 10 for example:
Since I do not have many 3rd party packages, can I:
Install a clean Laravel 10 project
Delete composer.json and composer.lock from the the existing Laravel 7 project
Copy the composer.json from the clean Laravel 10 project to the existing Laravel 7 project
Run composer update (or install) on the Laravel 7 project
manually install the few 3rd party packages (using require)
Follow the upgrade guides from 7>8>9>10 to update any code-related breaking change
@martinbean also to be honest, if you've seen the recent packagist compromising, I wouldn't trust composer completely either. And it's not that unknown packages were compromised, but very known packages. Lucky the attacker did that to get a job at Cyber security and didn't do malicious things. But really, gaining access to change composer packages like that is scary if your data is sensitive.
And ok you can say it was patched, but if these things happen once, you just don't trust it the same again
@Ligonsker So what‘s the alternative? Just write everything from scratch? And if so, where do you stop? Are you running Windows? Or macOS? Because they’re not infallible to being compromised either. So are you going to start writing your own operation system from scratch?
@martinbean Eventually there was a solution - to use a similar thing to Private Packagist, it's a paid system that you set as the repo instead of packagist in your global composer config, then all traffic goes through this system (then you set packagist: false). This system then connects to packagist as well, but before it lets you download anything, it scans it against all the vulnerabilities known to it (to the company running this system), it's pretty good, it blocks the download and tells u exactly the vulnerability of the package (And if you try to install a project like Laravel it will block the project installation and list all the vulnerable packages there). It links you to where source of the vulnerability - some links were to GitHub, some links were to the NIST CVE website
@martinbean true, but it's at least a known system and also this way the security team can have everything monitored in a centralized place so less likely to escape under their radar like when letting everyone do what they want (I saw the dashboard it's pretty cool). I think many companies use it, it seem to also have a free version - if you heard of Sonatype (In their website there's a list of some big companies using it, if you can believe this list). It's actually the one that blocked the recent compromised packages and gave links to the reasons
