Laravel-Tips and what a tip library gets right about Eloquent

A directory of tips, organised by subject

Laravel Tips is described as the daily Laravel and PHP tips the author shares on X and LinkedIn, with a note that longer articles live on his own blog. The repository is the collected stream, and the README says there are over 300 tips, categorised as follows.

Each category is a markdown file under a tips/ directory, and the top level of the tree is small enough to describe in one line: a README.md, a tips/ directory, a scripts/ directory, a stats.json file and a .github/ directory. The scripts are why the primary language is recorded as Shell rather than PHP, because the tips themselves are prose rather than code.

The category list is the best available description of what a Laravel developer actually needs help with, and it is worth reading as a survey rather than as a table of contents. Eloquent and database work leads with 98 tips, helpers follows with 67, testing has 29, Artisan and console commands 27, routing and request handling 23, validation 19, collections 17, API and HTTP client work 15, a catch-all of random cool tips 15, views 14, queues and jobs 14, the container 7, authentication and authorization 6, error handling 5 and AI 2.

The shape of that distribution is the interesting part. Nearly half the collection is about getting data out of and into the database, and the next largest block is about the framework's helper functions, which are exactly the tools people use without reading the documentation. Testing, by contrast, is a third of the size of the database category, which reflects a framework where the ORM is the hard part.

Eloquent and helpers carry the collection

The two largest categories are the ones that a working Laravel developer consults most, and they are also the two where the framework gives you the most surface area to get wrong.

Eloquent at 98 tips covers the model layer, the query builder behind it, relationships, scopes, eager loading and the various ways a query can be written. That is a lot of surface, and a lot of it has performance consequences, which is why a tip that says how to avoid a query in a loop is worth more than one that shows a slightly shorter method call.

Helpers at 67 tips covers the global function library, the small things that make code read better, the string, array and collection helpers that arrive with the framework, and the gaps in PHP's standard library that Laravel fills. The reason a tips collection is valuable here is that helpers are easy to use without reading about them, which means they are easy to use badly, and some of them are deprecated in newer versions.

That last point is the risk that runs through the whole repository, and it is not a criticism of the author, who writes a tip a day and publishes them immediately. It is a property of the format. A tip written against Laravel 9 may be written against a method that no longer exists in Laravel 12, and there is nothing in the repository structure that marks the version a tip applies to.

The categories that follow are smaller but more likely to be version sensitive rather than less, since testing, console and routing conventions have all shifted across the major versions.

The small categories tell you who writes this

Two categories at the bottom of the list are more revealing than the large ones.

AI has two tips, which says something about when the collection started and how quickly the framework world moved. Authentication and authorization has six, which is low for a category that every application needs and that Laravel has changed repeatedly. Container has seven, and the container is the part of Laravel that most developers use only by accident, through dependency injection in a constructor, without knowing that what they are doing is resolving from the container.

Error handling has five, which is the smallest non-AI category, and that is arguably the biggest gap in the collection. Laravel's exception handling, the reportable interface, the rendering pipeline and the job queuing failure path are all places where applications diverge in ways that are hard to reverse, and five tips is not many.

The testing category, at 29 tips, is the one where the repository's own tooling shows up. The topics list includes pestphp, which means the testing tips are at least partly written against Pest rather than only against the built-in PHPUnit runner. That is a meaningful signal about the author's stack, and it also tells you that a reader on PHPUnit has to translate some of the examples.

For a team, that distribution is a useful gap analysis. The categories with fewer tips are where your own house rules and internal notes will be more valuable than anything you find here, and the categories with many tips are where a tip that contradicts your convention is most likely to be useful precisely because it comes from outside your codebase.

Markdown files, a scripts directory and a stats file

The repository's structure tells you the format of a tip, because there is nothing else it could be. There is no package to install, no service provider, no trait to add. A tip is a section of a markdown file, and the files are grouped by the categories the README lists.

The scripts/ directory and stats.json explain the badges at the top of the README. One badge is a dynamic JSON badge that reads the totalTips field from the stats.json file in the repository, which means the count is generated from the content rather than typed in, so it cannot drift out of date. The other badge is a standard last-commit badge.

That is a small design decision with a large effect on trust. A hand-maintained count in a README is wrong within a month. A count derived from the files is right whenever the build runs, and the scripts/ directory is the mechanism that makes it so.

For a reader, the practical consequences are that the whole collection can be read in a browser with no setup at all, and that it can be cloned and searched with grep or ripgrep, which is the fastest way to answer a question like how to do something with Eloquent. The tips being markdown also means they translate to a static site or a wiki without conversion.

The contribution model is equally simple. The README invites pull requests with new tips or with improvements to existing ones, and the categories are the natural place to put a new one, so a contributor who has a tip about queues knows which file to open.

What this is not, and the version question it cannot answer

The obvious alternative is the official Laravel documentation, and the difference between the two is worth being precise about.

The documentation is canonical and versioned. Every feature it describes is tied to the release it was written for, and when a method is renamed or a default changes, the documentation changes with it. It is also exhaustive, which is a weakness for the reader who wants one answer rather than a chapter.

A tips collection is the opposite on both counts. It is not versioned, so a tip can describe behaviour that has since changed, and it is selective, so it will not tell you about the feature it does not happen to cover. What it gives you is the experience of one developer, condensed into sentences you can read in a minute.

Neither is better in general. Documentation is what you consult when you need the contract. Tips are what you read when you want to be reminded that the framework already solved the problem in front of you, which is a different job and a frequent one.

The honest limitation of this repository is the version question. Nothing in the file names, the category list or the badges ties a tip to a Laravel release, and the last commit badge tells you when the file last changed, not when the advice was written. A team that reads a tip, tries it, and finds that the method was removed two majors ago has learned something about the repository's limits, and that is worth knowing before you build a convention on top of it.

A tip stream rather than a library, with no licence file

The maintenance pattern is unlike a library's, and it is the same pattern as a newsletter.

There are no GitHub releases, and the repository's recent history is a series of commits that add or refine tips. The last push was on 2026-05-08. The upstream source of the material is the author's social accounts, X and LinkedIn, where the tips are shared daily, and the blog for the longer pieces. This repository is the archive of that stream, not a versioned library with a changelog and a support policy.

That has an upside and a downside. The upside is freshness, because a tip from a working developer appears the day it is learned, and the collection covers the parts of Laravel that people actually hit, including the AI category that would not exist in a documentation set. The downside is the version gap described earlier, and there is no release to pin to.

The licence is the other loose end. The repository's own metadata records no licence, and the top level of the tree contains no LICENSE file, so there is no stated grant for reuse. A tip is a sentence, and copying a sentence into an internal wiki or a code comment is a small thing, but a team that wants to publish the collection as part of its own documentation needs permission that the repository does not currently give.

The judgement for a reader is that this is a good scanning list and a poor dependency. Use it the way the author uses it, as a daily feed of things worth remembering, and check every tip against the version of Laravel your application actually runs.

Editorial conclusion

Adopt Laravel-Tips as a team reading list, a review checklist for pull requests, or a source of examples to adapt, since the tips are short, categorised and easy to scan. Do not treat it as a dependency or copy a tip into production without checking the Laravel version it was written against, because the repository carries no version markers. Verify three things first: which Laravel version each tip targets, since the advice changes across major releases, whether the tip you want is a framework feature or an opinion from the author, and what licence applies, because the repository has no licence file and no release history. The last push was on 2026-05-08 and the project publishes tips daily on the author's social accounts rather than as versioned releases.

Frequently asked questions

Official sources

1. Issues
2. OussamaMater/Laravel-Tips on GitHub
3. README