Fresh Package brings discipline to Laravel package developmentFresh Package brings discipline to Laravel package development

Starting a package is easy; keeping it healthy is not

Creating a Laravel package takes very little time until you need to test it outside one specific application, document its conventions, and keep changes compatible with supported framework versions. Most of us end up copying a composer.json, GitHub Actions workflows, and static-analysis settings from an older repository. Fresh Package turns that repeated setup work into a reusable foundation with those pieces already connected.

The template makes one useful assumption: a package should be developed and verified inside its own repository. It includes PHPUnit, Larastan, Rector, Pint, and Paratest as development tooling. It also declares support for Laravel 12 and 13 through illuminate/support, with Composer scripts to switch between both framework versions locally.

A workbench instead of a disposable host application

The most practical piece is the workbench/ directory built around Orchestra Testbench. Testbench can boot a Laravel application from within a package repository, while Workbench provides commands and configurable actions to preview, interact with, and serve the package during development. It does not replace integration testing in a real consuming application, but it removes the need to build a separate host project for every small change.

Fresh Package wires Composer scripts for package discovery, workbench builds, and local serving. That sounds minor, but it matters because the way to check a route, view, migration, or published asset is documented in the repository itself. For packages that expose UI resources or endpoints, that makes day-to-day work more direct.

{
  "scripts": {
    "build": [
      "@php vendor/bin/testbench workbench:build --ansi"
    ],
    "serve": [
      "Composer\\Config::disableProcessTimeout",
      "@build",
      "@php vendor/bin/testbench serve --ansi"
    ],
    "test": "vendor/bin/phpunit -c tests/phpunit.xml.dist --testdox --colors=always"
  }
}

Compatibility that can be checked locally

The repository provides composer switch:l12 and composer switch:l13. Those scripts change the illuminate/support constraint and run Composer updates, so framework support is not just a claim in a README file. You can then use composer test, composer analyse, and style checks against the selected version.

There is also support for parallel test execution and coverage reports. This does not prove compatibility with every dependency combination a user might have, but it gives maintainers a repeatable way to validate what the package says it supports. For public packages, I prefer that to discovering version issues only after someone opens an issue.

Quality tools from the first commit

Fresh Package does more than generate a service provider and a few classes. It includes scripts for static analysis with PHPStan through Larastan, code style checks with Pint, and automated refactoring with Rector. Having those tools in place from the start prevents the usual pile of type and formatting debt that nobody wants to clean up later.

Release and changelog automation are part of the package too, alongside optional repository settings such as Dependabot, a security policy, and issue templates. Those defaults still deserve a review before being enabled, but it is useful to have them available when a repository is created. The goal is not to enable everything; it is to make deliberate choices early.

Guidance for agents that stays with the codebase

The AI-related part becomes useful when it is treated as repository documentation rather than a marketing checkbox. Fresh Package separates guidance for maintaining the skeleton itself from rules that belong to generated packages. That distinction matters because an agent should not confuse template-maintenance rules with the conventions that package contributors need to follow.

Laravel Boost separates broad AI guidelines from focused skills that agents load when a task needs them. Boost also allows third-party packages to ship skills from resources/boost/skills/, so applications that install those packages can receive relevant instructions. Fresh Package offers that Boost integration as an option rather than making it a hard requirement.

The small print

I would not use this starter for every PHP library: it is designed for Laravel packages and assumes Laravel tooling, conventions, and workflows. A modular directory layout does not create good architecture on its own either; if the domain boundaries are wrong, better folders will only make the same problem look tidier. Skills can guide an AI agent, but they do not replace human review, meaningful tests, or knowledge of the package’s limits.

It is worth checking the Composer hooks that run after composer install and composer update, because the template starts its initialization flow through those hooks. The skeleton-maintenance skill also warns that running template:init directly in the skeleton repository is destructive and recommends its sandbox workflow for validating changes. If I were adapting Fresh Package as an internal company baseline, I would test the generator first and remove anything that does not match the team’s workflow.

Fresh Package makes sense when you repeatedly build Laravel packages and want tests, workbench support, quality tooling, and automation to share a verifiable baseline. It is not a universal recipe or a guarantee of good code, but it is a stronger starting point than copying an old package and deleting files until Composer stops complaining. That is where a starter earns its place: by making recurring decisions visible, executable, and reviewable.

Source: Laravel News

Official documentation: Fresh Package · Orchestra Testbench · Laravel Boost