The State of Laravel Packages in 2026, According to 200 Developers

At the end of November, I shared a questionnaire to discover what the community thinks about the state of Laravel packages today. I wanted to focus on the real-world pain points developers face. To ensure I got busy developers to respond, I kept it short, under 3 minutes on average.

Without an established audience, I managed to reach around 200 responses.

Thank you to everyone who participated or shared it; the insights gathered were eye-opening.

This article illustrates what the community had to say. 

Who responded to my survey about Laravel packages? 

To ensure the data reflected active ecosystem users, I first asked how often respondents develop new features or applications using Laravel.

82% develop new Laravel features Daily or Weekly. That number grows to 94% if we include monthly respondents. This tells me the majority of you aren't just maintaining legacy code; you're actively choosing Laravel for new work. That's awesome to see. 

(Going forward, the data below focuses on this active daily/weekly/monthly cohort to ensure relevance.) 

The "Build vs. Buy" Mentality 

When needing standard functionality (e.g., SEO, Media handling, Payments), what is the default reaction? Do developers reinvent the wheel or look for existing solutions? 

The results show a strong preference for existing solutions. 96% of respondents indicated they either immediately look for existing packages/SDKs (65%) or search for packages first before potentially deciding to build it themselves (31%). 

This confirms that Laravel developers prefer not to rebuild standard functionality unless forced to. Remember that detail for later. 

Where do developers find packages? 

I was curious if my personal habit of just Googling everything was normal. It turns out, it is. (Note: Respondents could select multiple options). 

Unsurprisingly, Web Search (74%) dominates. However, it is closely followed by Packagist (51%) and community news sources like Laravel News or newsletters (49%). Interestingly, developers seem to trust curated news sources and general web results significantly more than GitHub search (42%) or social media feeds (19%) when looking for tools. So, a bit surprisingly, this means we choose to trust other developers' recommendations via news sites more than random posts on social media. 

How heavy are our composer.json files? 

I asked how many third-party packages (excluding default Laravel dependencies) are in an average project to gauge the "baggage" we're willing to carry. 

Over half of the respondents (54%) fall into the 6–15 package range. Given standard best practices today (involving tools like PHPStan, Pint, Debugbar, or Telescope), this feels normal. 

I was surprised that 38% managed to keep projects between 0 and 5 packages, that is impressive discipline! Honestly, how do you manage to keep it so low? Please send me a DM, I'm very curious. Finally, 7% have 16 or more packages. That seems heavy, how long does your composer update take at that point? Luckily Composer is fast, but still. 

The Vetting Process 

How much time do you spend researching before typing composer require? 

• 61% spend between 5 and 30 minutes. 
• <5 minutes was the next largest group with 19%  
• 30% spend more than 30 minutes doing a deeper dive. 

This suggests that for the majority, the criteria chosen for selection needs to be scannable quickly, things like update recency, documentation quality, and popularity, rather than deep code audits. We have what Italians call "grilletto facile" (a quick trigger) for packages that look good on the surface. 

1. Recency of updates / Maintenance status 
2. Documentation quality 
3. GitHub Stars / Popularity 
4. Author reputation 

The quality and frequency of updates are clearly king. 

The Biggest Frustrations 

This was the most critical part of the survey: what makes developers unsatisfied with the current ecosystem? 

It is a statistical tie for the top frustration. 70% cited lack of documentation or usage examples, while virtually the same amount cited the issue of too many abandoned or outdated packages cluttering search results. 

We have all experienced searching for functionality and finding five packages that haven't been updated since Laravel 8.  

In third place (28%) was the difficulty of comparing features between similar packages. And finally, not knowing if a package is compatible with my Laravel version represents 13% of results.  

The Community Wish-list 

I finally asked an open-ended question: "If you could wave a magic wand and improve one thing about the Laravel ecosystem today, what would it be?" 

I received 32 wonderful, detailed responses. While some covered broader topics, the vast majority focused specifically on the pain of managing third-party packages.

Here are some representative voices from the community: 

On the broader community: 

• "...less expensive Laracons..." . I can understand this! Have you heard of LaravelLive.jp? The price is very low and Japan is... well, Japan, we could even meet for a coffee there.
• "More popularity with employers" . We all want this. 
• "Laravel patterns often don't scale well. More education around team-oriented patterns..." 
• "More focus on plain Laravel + Blade" and "I want to make it more type safe..." 

On packages specifically (this is where it got really interesting): 

• "Making keeping packages up to date for each Laravel version the norm. Many packages are abandoned after a few versions." 
• "Standardize package info presentation to include age of project, last update, version compatibility, preq, open issues." 
• "Less fragmentation of third party packages would be nice." 
• "Reduce the number of duplicate packages that do the same or similar functions." 
• "A Laravel centric site with packages including their usages... a dedicated site would be better." 

I also saw some direct debate in the responses, like requests for "More livewire support, fewer paid libraries" sitting right next to a simple "get rid of livewire". The community has strong and mixed feelings! 

Conclusion 

The data paints a clear picture: Laravel developers want to use packages, but the friction involved in finding reliable, well-documented, and up-to-date tools is a major pain point. The ecosystem is vibrant, but that vibrancy creates noise that is hard to filter. 

The recurring theme in your open-ended responses was a desire for a centralized, standardized way to evaluate packages specifically for Laravel. Those suggestions literally gave me an idea. 

Inspired by this data and your specific feedback, I started working on LaraPlugins.io as an attempt to address these frustrations. It’s a new directory focused on helping developers find, compare, and check maintenance status for Laravel-specific packages. 

The alpha of the site is up but with an initial health score algorithm.

I don't pretend to have the perfect way to judge article healthy so please give the site a try then send me a feedback on the site health score system.

Only a collective effort can produce something really useful to all of us.

in the incoming AI development having a trustworthy directory would make AI agents able to pick healthy packages for the development project.