Laravel packages are created by setting up a proper structure, writing service providers, distributing via Composer, and avoiding common pitfalls. First, create a directory with a composer.json for autoloading and Laravel integration. Second, build the core logic in src/ and register it via a Service Provider using register() and boot() methods. Third, distribute via Packagist by tagging releases and submitting to GitHub. Lastly, test installation steps, use PSR-4 correctly, avoid hardcoded paths, and always run composer dump-autoload after changes.

Laravel is a powerful PHP framework, and one of its strengths lies in how easily you can extend it using custom packages. If you’ve built something reusable — like a service integration, a set of helpers, or a specific functionality you want to reuse across projects — packaging it up makes sense. Here’s how to do that effectively.

Setting Up Your Package Structure

Before jumping into code, you need a proper structure for your package. Laravel uses Composer to manage dependencies, so your package should follow Composer standards.

You’ll typically start by creating a new directory outside your Laravel project (or inside packages if you're keeping everything together). Inside this folder, create the basic files:

• composer.json – This defines your package metadata.
• src/ – Where your actual code lives.
• Optional: tests, config, migrations, etc.

A minimal composer.json might look like this:

{
  "name": "yourname/laravel-package",
  "autoload": {
    "psr-4": {
      "YourName\\YourPackage\\": "src/"
    }
  },
  "extra": {
    "laravel": {
      "providers": [
        "YourName\\YourPackage\\YourPackageServiceProvider"
      ]
    }
  }
}

This sets up autoloading and tells Laravel which service provider to use when the package is installed.

Writing the Core Logic and Service Provider

The heart of any Laravel package is usually a Service Provider. This is where you register bindings, publish configuration files, and integrate with Laravel’s core.

Let’s say you’re building a logging utility. You’d have a class like Logger.php in your src/ folder, and then in your service provider’s register() method, you might bind it:

use YourName\YourPackage\Logger;

public function register()
{
    $this->app->singleton(Logger::class, function ($app) {
        return new Logger(config('yourpackage.log_level'));
    });
}

Also, if you need configuration, publish it from the service provider:

public function boot()
{
    $this->publishes([
        __DIR__.'/../config/yourpackage.php' => config_path('yourpackage.php'),
    ], 'config');
}

This allows users to run php artisan vendor:publish and customize settings.

Distributing Your Package via Composer

Once your package works locally, you’ll probably want to share it. The easiest way is through Packagist, which integrates directly with Composer.

Here’s what to do:

• Make sure your composer.json has correct versioning ("version": "1.0.0" or use tags).
• Push your package to GitHub (or another Git repo).
• Submit your repo to Packagist, or use automatic hooks.
• Tag releases using Git tags (git tag 1.0.0 -m "Initial release").

After that, anyone can install your package with:

composer require yourname/laravel-package

If you don’t want to publish publicly yet, you can still test it locally by pointing Composer to a path:

In your Laravel app’s composer.json:

{
  "repositories": [
    {
      "type": "path",
      "url": "../path-to-your-package"
    }
  ]
}

Then run composer require yourname/laravel-package --prefer-source.

Common Gotchas and Tips

There are a few things people often miss when developing Laravel packages:

• ? Always test installation steps fresh — delete vendor/ and reinstall to simulate a real user experience.
• ? Use PSR-4 correctly — mismatched namespaces and paths cause most autoload issues.
• ? Don’t hardcode paths — use __DIR__ or dirname(__FILE__) instead.
• ? Consider adding Laravel Octane compatibility if you expect high performance usage.
• ? Be careful with facades — they work but can make testing harder.
• ? Include a README with clear instructions on installation and usage.

One thing that trips people up is forgetting to run composer dump-autoload after changes — especially when working locally. It’s easy to think your changes aren’t working when really, Composer just hasn’t reloaded the class map.

Basically, developing and distributing Laravel packages boils down to following standard Composer practices and leveraging Laravel’s service provider system. Once you get the structure right, the rest flows pretty naturally.

No magic involved — just good organization and attention to detail.

The above is the detailed content of Developing and Distributing Custom Packages for Laravel. For more information, please follow other related articles on the PHP Chinese website!