When to pull in top-level dependencies

If Laravel already requires a package, is there ever a reason to install it into your project directly?

Joel Clermont
Joel Clermont

Last week, I warned about not explicitly installing dependencies if you don't need to. The key phrase there is "if you don't need to".

For example, if Laravel depends on a CommonMark package to create Markdown mail, but my code only references the Laravel Mailable class, there is no reason to install league/commonmark in my project's composer.json.

On the other hand, let's say I reference some of the CommonMark classes in my code to customize how Markdown code snippets are rendered. Now, I should definitely install it in my project directly. Why? A future Laravel upgrade could bump the package to a new major version or maybe remove it altogether. By installing it directly in the project, conflicts like this are blocked by Composer.

Thanks to Marco, I learned about a tool which detects these hidden dependencies: Composer Require Checker

Run it against your project, and it will flag any classes your code depends on that aren't directly installed in your project. It even flags code that depends on a PHP extension if it isn't explicitly required in composer.json.

Here to help,


P.S. Validation is really important in your app, but it doesn't always get the attention it deserves. We've written the ultimate guide to Laravel validation rules to help you get the most out of this powerful feature.

Toss a coin in the jar if you found this helpful.
Want a tip like this in your inbox every weekday? Sign up below 👇🏼

Level up your Laravel skills!

Each 2-minute email has real-world advice you can use.