# Laravel Packager for local package development

> Jeroen-G/laravel-packager is a Laravel Artisan tool that creates package directories, registers local packages, copies package tests, and supports GitHub publishing. It is aimed at developers building packages inside a Laravel application, not at a general-purpose Composer workflow.

**Jeroen-G/laravel-packager** — A cli tool for creating Laravel packages

- Repository: https://github.com/Jeroen-G/laravel-packager
- Stars: 1,368 · Forks: 187
- Language: PHP
- License: NOASSERTION
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/jeroen-g-laravel-packager

## Why Laravel Packager targets application-owned packages

Laravel Packager addresses the setup work that appears when a Laravel application begins hosting packages in its own source tree. The README says the tool creates a packages directory, adds vendor and package subdirectories, pulls in a skeleton, prepares composer.json, and creates a service provider. That is useful when the package needs the application's Laravel testing functions and service-provider environment during development.

The target user is a developer working on one or more local Laravel packages from inside an existing Laravel application. The workflow is centered on packages stored under the application's `packages/` directory. Commands can list these packages, copy their tests into the application, remove a package, and publish one to GitHub. The documentation does not describe a separate standalone application or a package-development environment outside Laravel.

The package is installed as a development dependency, which makes that boundary explicit:

```bash
composer require jeroen-g/laravel-packager --dev
```

For Laravel versions below 5.5, the service provider must be added to `config/app.php`. Laravel 5.5 and later use package auto-discovery, although the README also warns that auto-discovery loads the package in production. It therefore documents a conditional registration option in `AppServiceProvider`:

```php
if ($this->app->environment('local')) {
    $this->app->register('JeroenG\Packager\PackagerServiceProvider');
}
```

The project therefore treats Laravel Packager as development infrastructure, and its registration policy matters when the application is deployed.

## Artisan package creation and skeleton selection

The `packager:new` command performs the central creation workflow. A non-interactive invocation supplies a vendor and package name, while the interactive option allows values such as the license and package description to be entered during creation:

```bash
php artisan packager:new my-vendor my-package
```

```bash
php artisan packager:new my-vendor my-package --i
```

The README also documents the slash-separated form. The name still identifies a vendor and a package, but the slash changes the argument shape:

```bash
php artisan packager:new my-vendor/my-package
```

According to the README, the command creates the directory structure, retrieves a skeleton package, sets up `composer.json`, and creates a service provider. The default skeleton is maintained in the separate `jeroen-g/packager-skeleton` project. The configuration file can be published so a different service provider stub can be used, and a one-off skeleton can be supplied with `--skeleton`. The README documents a `--skeleton` flag for overriding the configured skeleton for one run.

That mechanism is the main extension point for teams. A team can change the default for all package creation calls through the published configuration, or use a different archive for a single call. The documentation does not explain how the skeleton archive is validated, nor does it specify which skeleton versions correspond to which Laravel releases, so compatibility must be checked before adoption.

## Registering packages from Git and managing local state

Laravel Packager can also bring an existing repository into the local package workflow. The `packager:get` command downloads a package without cloning the Git repository, while `packager:git` clones the complete repository. Both commands register the package in the application's `composer.json` file. The documented forms are:

```bash
php artisan packager:get https://github.com/author/repository
```

```bash
php artisan packager:git https://github.com/author/repository
```

The README says Bitbucket is supported for `packager:get` when `--host=bitbucket` is supplied. A branch can be selected with `--branch`, and explicit vendor and package names can be placed after the URL:

```bash
php artisan packager:get https://github.com/author/repository --branch=develop
```

```bash
php artisan packager:get https://github.com/author/repository my-vendor my-package
```

```bash
php artisan packager:git https://github.com/author/repository my-vendor my-package
```

The distinction between `get` and `git` affects the local state. `get` is suited to downloading package contents when repository history is unnecessary. `git` preserves a working repository and gives the developer the Git workflow described for local packages. By contrast, `packager:list --git` adds branch and commit-difference information for packages that are Git repositories. The README does not document authentication for private repositories, merge behavior, or how conflicts are handled.

## Package tests, listings, removal, and publishing

The testing command makes local package tests visible to the Laravel application. `php artisan packager:tests` walks through the maintained packages in `packages/` and publishes their tests to `tests/packages`. If a package already has a tests folder, its files are copied into a dedicated directory in the Laravel application's tests folder. The README says this lets package tests use Laravel's own testing functions.

To run those copied tests, the application needs a PHPUnit test suite entry:

```xml
<testsuite name="Packages">
    <directory suffix="Test.php">./tests/packages</directory>
</testsuite>
```

A particular package can be selected by adding its vendor and name:

```bash
php artisan packager:tests my-vendor my-package
```

The list command gives an overview of the packages in `/packages`:

```bash
php artisan packager:list
```

With `--git`, the displayed information includes Git status, the branch, and the commit difference with the origin. This is a repository-oriented view rather than a Composer dependency report.

Removal is similarly explicit:

```bash
php artisan packager:remove my-vendor my-package
```

The README says this deletes the package and its references in `composer.json` and `config/app.php`. Publishing uses the repository URL supplied on the command line:

```bash
php artisan packager:publish my-vendor my-package https://github.com/my-vendor/my-package
```

The documentation does not say how authentication or GitHub credentials are supplied for publishing, so those details should not be assumed.

## Security checks and documented operational constraints

Laravel Packager includes a package-specific security check command. Before using it, the README requires installing the SensioLabs security checker:

```bash
composer require sensiolabs/security-checker
```

After that dependency is available, a local package can be checked with:

```bash
php artisan packager:check my-vendor my-package
```

The README states that the command checks the package for security vulnerabilities using the SensioLabs security checker. It does not describe the checker's output format, supported dependency sources, or behavior when the checker cannot reach its service. Consequently, the command should be treated as a project-specific integration point rather than a complete security policy.

Two operational constraints are documented directly. On some Windows systems, downloading the skeleton can fail because an operating-system SSL certificate file is missing. The README suggests this setting in `.env`:

```text
CURL_VERIFY=false
```

It explicitly notes that this reduces transport security. The setting is therefore a troubleshooting workaround, not a suitable normal production configuration. Package creation can also encounter timeouts. The README says the timeout can be changed in `config/packager.php`, but it does not provide the key or an example value, so the exact configuration edit cannot be reproduced from the available documentation.

## Maintenance, licensing, and adoption boundary

The repository is not archived, and its last push was on 2026-09-01. Recent releases listed for the project are 2.12.0 on 2026-03-20, 2.11.0 on 2025-03-09, and 2.10.0 on 2024-03-31. These dates show recent repository activity and published versions, but the available documentation does not specify a support window or a compatibility policy for individual Laravel versions.

The README identifies the license as the EU Public License and points readers to `license.md`. The repository metadata categorizes it as a custom license that GitHub cannot classify, so an adopting organization should read the actual `license.md` before distributing generated packages or modifying the tool. This is a licensing fact, not legal advice. The default skeleton is a separate repository, and its license or contents are not described in the README. That creates a separate check for teams planning to publish packages based on it.

The project is a good fit for a Laravel application that keeps several packages under `packages/` and repeatedly performs local setup, registration, listing, testing, or publishing. It is the wrong choice when the requirement is a Composer-only package workflow, a non-Laravel PHP package, or deployment infrastructure that should never load a package-discovery component. For an existing codebase, verify the Laravel version, the generated `composer.json`, the selected skeleton, and the `license.md` before making the tool part of the standard development path.

## Conclusion

Adopt Laravel Packager when you repeatedly build packages inside a Laravel application and want a consistent local directory layout. Do not adopt it as a replacement for Composer or a standalone Git workflow. Check the skeleton compatibility, Composer configuration, and the EU Public License first, then confirm that the generated package behaves as intended in the application's supported Laravel version.

## FAQ

### How do I install Jeroen-G/laravel-packager?

Install it as a development dependency with Composer. Laravel 5.5 and later use package auto-discovery; earlier versions require adding JeroenG\Packager\PackagerServiceProvider to config/app.php.

### How do I create a new Laravel package with Jeroen-G/laravel-packager?

Run `php artisan packager:new my-vendor my-package`. Add `--i` for interactive configuration, or provide a different skeleton archive with `--skeleton` for that run.

### How do I run tests for local packages with Jeroen-G/laravel-packager?

Run `php artisan packager:tests`, then add the documented `Packages` test suite to `phpunit.xml`. You can select one package by passing its vendor and name after the command.

## Sources

- [Issues](https://github.com/Jeroen-G/laravel-packager/issues)
- [Jeroen-G/laravel-packager on GitHub](https://github.com/Jeroen-G/laravel-packager)
- [README](https://github.com/Jeroen-G/laravel-packager/blob/master/README.md)
- [Releases](https://github.com/Jeroen-G/laravel-packager/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jeroen-g-laravel-packager