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. Daily or Weekly 94% (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%). 96% 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. Web Search (74%) Packagist (51%) Laravel News or newsletters (49%) GitHub search (42%) (19%) 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. (54%) 6–15 package 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. 38% 0 and 5 packages, 7% 16 or more packages 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. 61% spend between 5 and 30 minutes. 61% 5 and 30 minutes <5 minutes was the next largest group with 19% <5 minutes 30% spend more than 30 minutes doing a deeper dive. 30% 30 minutes 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. grilletto facile Recency of updates / Maintenance status Documentation quality GitHub Stars / Popularity Author reputation Recency of updates / Maintenance status Recency of updates / Maintenance status Documentation quality Documentation quality GitHub Stars / Popularity GitHub Stars / Popularity Author reputation 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. 70% lack of documentation or usage examples too many abandoned or outdated packages 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. (28%) 13% 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?" "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: 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..." "...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. "...less expensive Laracons..." LaravelLive.jp "More popularity with employers" . We all want this. "More popularity with employers" "Laravel patterns often don't scale well. More education around team-oriented patterns..." "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..." "More focus on plain Laravel + Blade" "I want to make it more type safe..." On packages specifically (this is where it got really interesting): 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." "Making keeping packages up to date for each Laravel version the norm. Many packages are abandoned after a few versions." "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." "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." "Less fragmentation of third party packages would be nice." "Reduce the number of duplicate packages that do the same or similar functions." "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." "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! "More livewire support, fewer paid libraries" "get rid of livewire" 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. LaraPlugins.io LaraPlugins.io 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. P.S. Laravel is a trademark of Taylor Otwell. LaraPlugins.io is an independent, community-driven directory and is not officially affiliated with, endorsed by, or sponsored by Laravel or Taylor Otwell. Trademark usage is intended solely to identify the Laravel framework and its ecosystem packages.​ P.S. Laravel is a trademark of Taylor Otwell. LaraPlugins.io is an independent, community-driven directory and is not officially affiliated with, endorsed by, or sponsored by Laravel or Taylor Otwell. Trademark usage is intended solely to identify the Laravel framework and its ecosystem packages.​

This story will praise and/or roast a product, company, service, game, or anything else people like to review on the Internet.

No More Slow Search: LaraPlugins Just Went Sub-Second

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

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

An AI-Powered Workflow Automation Guide: How You Can Self-Host n8n with Docker Compose and Traefik

Why Being Likable At Work Matters

Windows Sticky Keys Exploit: The War Veteran That Never Dies

Is ‘bias for action’ making product managers lazier?

Zero People Charged With Online Pirating, Swedish Prosecutor's Office Reports

What No One Told Me About Being a Product Manager at an Early Stage Startup

An AI-Powered Workflow Automation Guide: How You Can Self-Host n8n with Docker Compose and Traefik

Why Being Likable At Work Matters

Windows Sticky Keys Exploit: The War Veteran That Never Dies

Is ‘bias for action’ making product managers lazier?

Zero People Charged With Online Pirating, Swedish Prosecutor's Office Reports

What No One Told Me About Being a Product Manager at an Early Stage Startup

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps