Dozens of miscellaneous tips: https://laraveldaily.com/tips
Tighten’s Technical Debt Self-Assessment for Developers
Use Laravel Pint or Tighten Duster – they’re so easy to use (versus doing lots of manual PhpStorm configuration, for example) and you can add them as git pre-commit hooks which will only scan files that have changed, so they’ll be fast.
Pint is also useful for cleaning up things that used to be best practice, such as adding parameters to function DocBlocks, but which should now only be written directly in the code of the method itself.
The new Laravel Prompts are great. They are prettier (nice colours, borders and icons) and they neatly handle all the edge cases, including keeping the screen tidy if input validation fails and you need the user to enter an answer again, or if the script is aborted. There are placeholders and default options, and single and multi-select which support Vim keybindings. Each component is a namespaced function that is easy to insert.
If your app has no tests at all, start by doing some “smoke” tests to check all your main routes are functioning. These can be quite brittle.
Turn preventAccessingMissingAttributes on for your Eloquent models. (In dev only.)
Move from Laravel Collective to spatie/laravel-html if you haven’t already (in my experience you can convert <form> tags to plain HTML but you’ll probably still want the package for the convenience of coding select dropdowns and certain radio buttons and checkboxes.
In particular, check that you have @csrf on all your forms and directives like @method('PATCH') where you need them. If you can, write tests that your forms can be submitted. Use this automated Laravel Shift, it’ll save a lot of time but it definitely won’t do everything. You do need to test every form, unfortunately.
When writing tests in general, prioritise Feature tests over Unit tests. Save yourself time and increase accuracy by examining the view data you get back rather than using assertSee (which blindly scrapes the output). Laravel Dusk is handy for things you can only really check in a browser.
Using old hardware: if a Mac is no longer receiving software updates and consequently Homebrew is unreliable or takes ages to compile, consider using Macports instead, which, for example, still has the very latest PHP versions. (I found those were very quick to install and only MariaDB took 20 minutes+ to build from source.) You can also use artisan serve or even just PHP’s built in server (php -S). And for editing you have Nvim. I certainly wouldn’t do “serious development” an old machine, but it makes a great backup.
A short verbatim quote I enjoyed from Matt Stauffer’s “Laravel and in the enterprise” talk at this year’s Laracon (there’s plenty of other good stuff in the full thing):
“People imagine that if they do “API-first” they’ll build an API, they’ll build an SPA in front of the API, and later they’ll get a free mobile app API out of it and they’ll build the mobile app and it won’t be any work.
What happens in reality is it takes three times as long to build your web app as it would if you’d just used native technologies, you have to learn SPAs, you end up building an API that’s super, super super tightly integrated with your SPA and then one day if you do eventually maybe have a mobile app it turns out it doesn’t need the same API resources and routes that you built because you didn’t really build a true REST API you built one that served that SPA, and you just have a second API now.
So your web app took longer to build, it’s more complicated and you have two APIs.”
Matt Stauffer (Tighten)
(you can do a nice, simple SPA, including persisting elements like an audio player, with Livewire 3)