Careful, Laravel Commands are not careful

The more I look the more I see that Laravel overwrote more than just some files... they wrote over many files. This sucks. I can say for sure that Laravel, may create great CMS but they at the same time not responsible. They have destroyed all the work!!! Laravel you are really beginning to be an organization that we can trust less and less.... you don't even follow basic principle of courtesy!

there used to be a saying: admins are divided into 2 categories. those who make backups and those who do not make backups yet. years of practice taught me to put even the simplest project into a git right away. and read documentation before install anything. look at it as an experience, use git, use ide with local history like phpstorm and don't blame the framework for your mistakes. if I wanted to develop on a framework with a bunch of foolproof protection, I would choose a graphics framework, my son has one. Well, throw a pull request into the breeze github, which warns during installation that your route/web.php is not empty. sure breeze suspects that it is being set into a new project.

So you are saying that Laravel, should. not warn you of overwritting many files and that it should not check, because big tech does not need to do things like this, they leave up to the programmer to trust or not to trust and up to the programmer to prevent him/herself from not getting screwed by the big tech who already knows that courtesy is a thing of the past and thus does not need to, nor should it warning of things that it will do on your servers/ computers?????! Like overwriting files without warning!

Scaffolding does not necessarily mean to overwrite files where and whenever it so desires. Scaffolding means that they will create something to make it easier on you, it does not to allow them to overwrite things that are already there, especially without warning!!!!!!!!! Many programs warn you! Many. Just Laravel, does not!!!!!

This install not only overwrites some files it changes even your complete configuration, 100%. It does not take in account anything! It overwrites everything!

No Framework, should have the right to override everything! Are you telling me that this guy @TaylorOtwell just needs to create new stuff, but not be expected to add an if condition in a script that allows the user a chance to choose if he wants to wipe out his/her existing settings, and files!? That install wipes out your app.js file your bootstrap.js your routes/web.php any files sitting inside the views/ folder that might have the same name as his stuff! This attitude that he does not need to think about courtesy during install is very wrong!

@TaylorOtwell, you need to be called out! You should not just override people's code and file structure to install your own! You need to always take in to account that not every person is going to understand the way you think! It is not even enough to say read the documentation, because there 1000's of tutorials and places to read on Laravel documentation that does not say in plain English: "By installing this, or by running this command, we will be overwriting so many files that you stuff will no longer work after we install X feature!!!!"

I've been in your situation and I understand your pain) but you are wrong. Again, treat this as a new experience. well and a great way to refactor your code

How am I wrong? You should not just override people's code and file structure to install your own! You need to always take into account courtesy!!!!!!!!!

All this time you could've done this:

1. Restart your project
2. Taking a break, time to clear your mind, telling yourself you should move on and learn from this mistake so it doesn't happen ever again.
3. Admitting you could've been wrong? e.g. (and this is just speculation) maybe you didn't read the documentation? Ouch (yes im talking to you, ego)
4. Analyzing, if, maybe, the context in which you understood the introduction to Breeze, was, perhpaps, (and im trying to be veeeeery careful), was, "somehow" gulp WRONG?
5. Done something to relax you and come at it at another time.

But no. You chose to complain.

So this is yet another suggestion: you be careful. Complaining can do great damage to your brain. However I am truly sorry for your loss, @niran. https://www.entrepreneur.com/article/281734 go watch some funny dogs or cats videos or something!

I know it's too late, but I always back up everything before I make any big changes.

While it would be tedious, a month of work is a lot so it might be worth trying to use CTRL+Z to undo the file changes. One way to narrow down which files were changed would be to install a new laravel project, and set up a first git commit. Then you could install breeze on your fresh project and see what files were changed from the initial commit, giving you a good starting point to undo changes in your project that got overwritten.

The year is 2021, how are you not using some type of Version Control System or at least making a daily ZIP backup of your project? (especially if you worked so hard on it and it was of great importance to you).

What would happen if you suffered from catastrophic disk failure? Would you complain to Western Digital?

What if your PC was hijacked by a virus or ransomware? Or if you just made a mistake doing a global search and replace?

The year is a long time before 2021, how are a backup of your project, specially when your 'test' new command. It's rule number one for every IT works (not only for dev)

That's said, you are not (totally wrong), using starter kit on a not empty project could warn.

@niran I submitted a PR to the Laravel documentation.

https://github.com/laravel/docs/pull/6834/commits/ac80d49c4384502948384334e9c5b7824da23748

This probably should be on there, that's fair to say...

With that said... not backing up your project or running a version control system, then installing any kind of package is just begging for a catastrophic problem. I would suggest you reflect on that and fix your process so that doesn't happen again.

I would also strongly urge you to be more respectful to people who are creating these tools that you benefit from. There are MANY pitfalls of programming that do not hold your hand or warn you. Pretty much every dev at some point has run a rm -rf or dropped tables they didn't mean to. You learn from it and you grow if you own the responsibility for it.

Apologies, but you cannot refer to someone as "this guy" when they are spending their precious time to offer free stuff so that you can write better & secure software . Fabien Potencier(Creator of Symfony Framework) has said this before about open source: "The illusion of getting software for “free”: Open-Source contributors are the exploited slaves of the modern programming world."

https://twitter.com/fabpot/status/967337512535576576

the rm command can be quite dangerous if you don't bother to learn what it does.

Yet, it trusts me to know what I am doing

I do, but I refrain from referring to it as its not relevant to any current problems.

OP just needs to learn to use a version control system, and use a cloud based git repository = no backup issues.

I really like to help people here and I'm always patient and try to politely explain the issue with someone's code or thought process, but politeness and respect goes both ways, so sorry in advance if I seem a bit crude.

You keep bashing Taylor like he represents the only source of responsibility in the unfortunate event you encountered, but in reality, you're the only master of your craft. Are you basically telling us that if you burn your steak, you're not the one responsible, but the butcher is for not telling you how to cook it properly?

You should grow from your mistake(s) instead of pointing fingers. For example, today one of our interns ended up with an unintended Git stash/pop related error. Did he blame Git for not telling him that it could create a merge conflict? No. He tried to understand why it happened. This is the type of attitude you should thrive for. Learn why something happened instead of blaming anyone but you.

So even though countless of people on this thread mentioned it already, here are two steps you can take to make sure you never encounter this type of problem in the future:

1. Use a version control software, such as Git, so you can keep track of your project's evolution, and revert back to the latest stable increment if something happens.
2. Keep backups of your folders/files.

Sorry but, this is how I picture you right now.

What he said.

Use a version control software, such as Git, so you can keep track of your project's evolution, and revert back to the latest stable increment if something happens.

Keep backups of your folders/files.

------Sorry but duh..

Don't blame TO for a rookie mistake on your part. I use git discover exactly what artisan commands do. Check your project in, run the command do a git status.

Wow! Thanks for all your input/energy on this post!

Lol, you guys are all correct :), I do think that frameworks should be more backwards compatible. It is true that I should use git and believe me "I do," but for a project I was working on, this one... I did not push it yet, that was my bad! None-the-less, it is quite important to be backwards compatible. Sorry @taylorotwell, it is not your fault, we have all been contributing to the big mess of backwards compatibility :(.

See this Wikipedia article: https://en.wikipedia.org/wiki/Backward_compatibility#:~:text=Backward%20compatibility%20can%20be%20used,value%20of%20supporting%20older%20software.

Although functionality (INTERNALLY) might change, we should do more to keep things working even when the way things work inside change. Also, it might be a SMART idea to include a feature to add a change and then add a switch that can turn on/off a new package that was introduced.

Similar to a version control system, their could co exist a version control like library that could allow versioning of builds on a development level, not a GIT level, but similar, maybe even use git to do this for us in the background on another specified path to backup all things before running a package install, either through composer or artisan commands.

Guys/Gals, what I see in the big picture is that when working on LARGE projects, whatever you interpret as LARGE, being able to easily upgrade to the latest releases (versions) should be able to do so without having to refactor(re-code) your projects. The TRUTH is that when a feature that was popular is just removed or is changed (DRASTICALLY) then you are faced with a decision to DROP the current framework, or write/hack your own version to work with your existing system (usually a project that grows becomes more of a system than just a project). We/Company's/Bosses' all want to be able to use that latest feature, but when faced with constant upgrades and issues with backwards compatibilities it is so hard to do so. Should it be this way? Taking a look at this article https://medium.com/ironkeel/breaking-backwards-compatibility-81c7986f234b we/you/me find it a problem to have to always be chasing the updates and keeping our System relevant with today's standards and technologies.

I, for one, think that being relevant without having to rewrite layers(changing code everywhere) of code, but having procedures/rules in place that would allow even older code to conform to new changes, via interfaces, is not only ideal but a necessary evil (must be implemented to save the hell that follows with upgrades/updates) and possibly even be the right thing to do (the way to go) moving forward.

Of course, I am only one person, but I think that many of you share some of the same sentiment mentioned above.

What are your guys/gals thoughts? @jeffreyway, @taylorotwell, @everyone!?

@niran my thought is I don't see big drastic changes between version 6 of laravel version 8.

Yes of course there are changes if you use the very latest Stacks offered. But I use fetch Js and regular JavaScript and bootstrap and custom CSS, and that's it.

So I currently have a version 8 and of course there were a few changes because of PHP 8 but that had nothing to do with laravel. Like the order of parameters.

And git Version Control that is in development, you push to a staging.

The trick is if you are going to use something new that's not in your current version don't try to do it overnight take time and migrate over keeping your current application backed up.

An example I went from some Jquery stuff to fetch Js, but believe me I had everything backed up as a just in case.

But this post will help others as well, it will remind people to definitely backup data before any changes, and don't feel alone we have all done something similar in the past that's how we learn.

@jlrdw let's get beyond the git and backup stuff, as this is clear that we ALL must do this. The point now, is to read my last post and to reflect on that. There are drastic changes to the UI, by the way. That is what happened when I used the artisan command to install a newer scaffolding that will break, for one because it overwrites files all over the place... but what I am referring to, at this point, is to building into the either/both the practices to create more interfaced libraries that don't just make it or break-it code that already exists = ). Well... please just read my previous post = )

Cheers mate!

@niran the UI is the same, there is a big difference between Breeze and the UI.

In other words an upgrade from version 6 to 7 then 7 to 8 would not have broke things.

Laravel has not changed that much in quite some time. What has changed is the extras you can use and the different scaffolding it has now but remember all that is optional.

Now me I did set up one of each just to play with them and learn them some. If I had to pick one of the new ones I would go with Breeze, just my preference.

But don't forget the Authentication chapter he also covers how to do the manual Authentication.

But bottom line don't compare laravel to all the add-ons and libraries and vue, interia, jetstream, all that stuff, the basic laravel is the same.