Building Reusable Laravel Packages from Scratch

Introduction

When developing multiple Laravel projects, you’ll often reuse the same logic, helpers, or UI components. Instead of duplicating the code, Laravel lets you build packages — reusable pieces of functionality that can be dropped into any project. This article teaches you how to build Laravel packages step by step, turning your custom solutions into reusable and distributable tools.

We’ll cover:

• Why and when to create packages
• Laravel package structure
• Building a demo package
• Service providers and autoloading
• Publishing assets and configurations
• Testing and distributing your package

Why Build Laravel Packages?

Packages are all about reusability and modularity. They let you encapsulate code in a way that’s portable and shareable.

Common Use Cases

• Custom authentication drivers
• Reusable UI components (like alert systems, charts)
• API wrappers (Twitter, Google Maps, etc.)
• Helper utilities for common business logic

Benefits of Packages

By moving logic into a package, you gain:

• Cleaner project structure
• Easy updates across multiple projects
• Ability to share with the open-source community
• Better testing and isolation

Setting Up the Environment

Before we build, ensure you have a working Laravel installation and Composer installed on your system.

Check Composer

composer --version

Create a New Laravel Project

laravel new package-demo

Step 1: Creating the Package Directory

By convention, Laravel packages are stored in a packages/ directory at the project root.

mkdir packages
cd packages
mkdir myvendor
cd myvendor
mkdir alert-system

Your folder structure should look like this:

package-demo/
├── app/
├── bootstrap/
├── config/
├── packages/
│   └── myvendor/
│       └── alert-system/
└── ...

Step 2: Initialize Composer

Inside your alert-system package directory, run:

composer init

Provide details like package name (myvendor/alert-system), description, author, and PSR-4 autoloading path.

Step 3: Package Structure

Here’s a typical structure:

alert-system/
├── composer.json
├── src/
│   ├── AlertServiceProvider.php
│   └── Alert.php
├── config/
│   └── alert.php
├── resources/
│   └── views/
│       └── alert.blade.php
└── routes/
    └── web.php

Each folder has a role:

Step 4: Create a Service Provider

Service providers are the heart of every package. They tell Laravel how to load and use your package.

// src/AlertServiceProvider.php
namespace MyVendor\AlertSystem;
use Illuminate\Support\ServiceProvider;
class AlertServiceProvider extends ServiceProvider
{
    public function boot()
    {
        // Load views
        $this->loadViewsFrom(__DIR__.'/../resources/views', 'alert');
        // Publish config
        $this->publishes([
            __DIR__.'/../config/alert.php' => config_path('alert.php'),
        ], 'config');
    }
    public function register()
    {
        $this->mergeConfigFrom(__DIR__.'/../config/alert.php', 'alert');
    }
}

Step 5: Register Package in Laravel

Edit your main composer.json and add:

"autoload": {
  "psr-4": {
    "MyVendor\\AlertSystem\\": "packages/myvendor/alert-system/src/"
  }
}

Then run:

composer dump-autoload

Finally, register your service provider in config/app.php:

'providers' => [
    MyVendor\AlertSystem\AlertServiceProvider::class,
],

Step 6: Add Config and Views

Create a config file:

// config/alert.php
return [
    'default_type' => 'info',
];

Create a Blade view:

<div >
 {{ $slot }}
</div>

Step 7: Using the Package

Now you can use your package’s Blade view in any Laravel project:

<x-alert type="success">
  Operation successful!
</x-alert>

This will render the custom alert box defined by your package.

Step 8: Publishing Your Package

To share your package with others, you can:

• Push it to GitHub
• Submit it to Packagist (so others can install via Composer)

Push to GitHub

git init
git add .
git commit -m "Initial commit"
git remote add origin https://github.com/myvendor/alert-system.git
git push -u origin main

Submit to Packagist

Go to Packagist.org, sign in, and submit your GitHub repository. Others can then install your package with:

composer require myvendor/alert-system

Best Practices for Package Development

• Always provide documentation in a README file
• Use semantic versioning (e.g., 1.0.0)
• Include tests for reliability
• Allow users to publish config and assets
• Keep your package focused on one responsibility

Conclusion

Packages are the backbone of Laravel’s ecosystem. By learning how to create reusable Laravel packages, you not only improve your workflow but also have the chance to contribute back to the Laravel community.

In this guide, we built a simple alert system package, registered a service provider, published configurations, created Blade views, and explored how to share your package with the world.

Next time you find yourself repeating code across projects, consider turning it into a package — future you will thank you!