goodm4ven/anvil
Anvil is a Laravel/PHP package that helps you forge robust applications faster. It bundles practical utilities and sensible defaults for common development tasks, reducing boilerplate and keeping your code clean, expressive, and easy to maintain.
Reality check first. goodm4ven/anvil is an internal package with zero stars, zero dependents, and no public documentation beyond the agent guidelines in its repo (AGENTS.md plus the Laravel Boost/Codex setup refreshed in v1.3.8). Treat it as a reference implementation / scaffolding kit for Laravel package development, not as a supported library. Before adopting it, budget an hour to read the source: composer.json, src/, tests/, config/, and any workbench/ or testbench.yaml files.
Installation. It is not a mainstream Packagist package, so pull it via a VCS or path repository. Releases are tagged (latest: v1.3.8), so prefer a tag constraint over dev-main:
{
"repositories": [
{ "type": "vcs", "url": "https://github.com/GoodM4ven/PACKAGE_LARAVEL_anvil" }
],
"require-dev": {
"goodm4ven/anvil": "^1.3"
}
}
Then composer update goodm4ven/anvil. If it is only intended as a template, skip require entirely and use it as a GitHub template / composer create-project source instead.
Where to look first.
composer.json — autoload PSR-4 namespace, required PHP/Laravel versions, scripts (test, format, analyse), and whether it depends on orchestra/testbench. v1.3.8 is explicitly a dependency-refresh release, so re-read this file rather than trusting older notes.src/ — the service provider and any base classes (TestCase, ServiceProvider, commands) you are meant to extend.tests/ — the canonical example of how the package expects to be tested; copy this pattern into your own packages.phpunit.xml / testbench.yaml — how the package boots a Laravel app for tests..github/workflows) and the agent config (AGENTS.md, Codex/Boost setup) — the intended PHP/Laravel version matrix and the house coding conventions.First use case. The most likely day-to-day use is: clone/copy Anvil as the skeleton for a new internal Laravel package, rename the namespace, and reuse its test harness. Concretely:
git clone --branch v1.3.8 https://github.com/GoodM4ven/PACKAGE_LARAVEL_anvil my-package
cd my-package && composer install && composer test
or composer create-project with the same VCS repository. Confirm the baseline passes on your PHP 8.3 environment before you change anything.
Template-first, dependency-never. The safest pattern is vendoring the structure rather than depending on it at runtime. Copy the service provider, test case, CI config, and agent guidelines into your own repo, adjust namespaces, and own the code. This avoids a dependency on a package with no public support story — even one that now ships tagged releases.
Pin to a tag, review the diff between tags. v1.3.8 is a patch bump whose only public note is "Updated packages and codex setup". Those dependency bumps can silently raise minimum PHP/Laravel or Testbench versions, so before upgrading a fork, diff composer.json and composer.lock across v1.3.7...v1.3.8 rather than reading the changelog line alone.
Use it as the base for a package service provider. Typical shape you should expect to adapt:
declare(strict_types=1);
namespace GoodM4ven\Anvil;
use Illuminate\Support\ServiceProvider;
final class AnvilServiceProvider extends ServiceProvider
{
public function register(): void
{
$this->mergeConfigFrom(__DIR__ . '/../config/anvil.php', 'anvil');
}
public function boot(): void
{
$this->publishes([
__DIR__ . '/../config/anvil.php' => config_path('anvil.php'),
], 'anvil-config');
$this->loadMigrationsFrom(__DIR__ . '/../database/migrations');
$this->loadRoutesFrom(__DIR__ . '/../routes/anvil.php');
$this->loadViewsFrom(__DIR__ . '/../resources/views', 'anvil');
$this->loadTranslationsFrom(__DIR__ . '/../lang', 'anvil');
}
}
Extend it in downstream packages only if you must; otherwise copy the relevant blocks into your own provider so upgrades are not coupled to the upstream repo.
Testing with Orchestra Testbench. If Anvil ships a base TestCase, your package tests will look like:
declare(strict_types=1);
namespace GoodM4ven\Anvil\Tests;
use Orchestra\Testbench\TestCase as BaseTestCase;
abstract class TestCase extends BaseTestCase
{
protected function getPackageProviders($app): array
{
return [AnvilServiceProvider::class];
}
protected function defineEnvironment($app): void
{
$app['config']->set('anvil.enabled', true);
}
}
Run tests with whatever script the package defines (composer test), not a hand-rolled phpunit call — the script usually wires up testbench correctly.
Composer scripts as a workflow contract. Internal package skeletons typically centralise quality gates. Use them in CI and locally identically:
{
"scripts": {
"test": "vendor/bin/phpunit",
"test:coverage": "vendor/bin/phpunit --coverage-html coverage",
"format": "vendor/bin/pint",
"analyse": "vendor/bin/phpstan analyse"
}
}
Agent tooling as a first-class asset. v1.3.8's "codex setup" confirms the repo ships AI-assistant configuration alongside AGENTS.md. If you fork it, treat those files as part of the package: they encode the strict-types/return-type/PHPDoc conventions your team wants, and stale ones will keep generating code in an outdated style after you bump Laravel.
Integration in a host app. For local development of a package against a real app, use a path repository with a symlink, and composer update goodm4ven/<your-package> after changes:
{
"repositories": [
{ "type": "path", "url": "../my-package", "options": { "symlink": true } }
]
}
Anvil's skeleton likely makes this frictionless because the provider, config publishing, and migrations are already wired.
CI matrix. If the repo ships a GitHub Actions matrix, adopt its PHP × Laravel combinations, then bump them yourself — the archived/skeleton matrix may lag behind currently supported Laravel versions. Re-check after each Anvil dependency refresh.
Low-maintenance means low-signal. No security-patch guarantees, no issue triage, and changelog entries as terse as "Updated packages and codex setup". Vendor the parts you need, pin a tag, and plan to replace it. Do not let it become a transitive dependency of packages you publish to Packagist.
Tags exist, but constraints still bite. v1.3.7 and v1.3.8 are tagged, so ^1.3 resolves — but if the repo's composer.json name does not match the slug, or you reference a branch that never gets tagged, installs fail silently. Verify with composer show goodm4ven/anvil after install and inspect the actual installed tree.
Service provider auto-discovery. If extra.laravel.providers is declared, the provider registers automatically in the host app. If you are copying the skeleton, remove or rename that key, otherwise you can end up with the Anvil provider loaded alongside your own — double-registering config merges and publish tags.
Config publishing tags collide. publishes(..., 'anvil-config') colliding with another package's tag is a common source of "why didn't my config publish?" Rename tags to match your package (my-package-config, my-package-migrations) when forking the skeleton.
mergeConfigFrom must be in register(), not boot(). If you refactor the provider, keep it there or config:cache will behave unexpectedly — values set by the host app in config/anvil.php will win over the package defaults only if the merge happens at register time.
Migrations and loadMigrationsFrom. Publishing migrations from a package means the host app controls the run order. If your package's migrations reference tables from the host app, document the required ordering and prefer Schema::hasTable() guards over assumptions.
Testbench version lockstep. orchestra/testbench major versions track Laravel majors (Testbench 9 ↔ Laravel 11, 10 ↔ Laravel 12). v1.3.8 refreshed dependencies, which may have moved the Testbench pin — check before assuming your earlier notes still hold, and upgrade Testbench deliberately rather than letting the lock file tie you to an EOL Laravel.
Strict types and conventions from the repo's agent guidelines. AGENTS.md mandates declare(strict_types=1);, explicit return types, constructor property promotion, and PHPDoc over inline comments. If you fork Anvil, apply these consistently — mixed conventions in a skeleton propagate into every package created from it, and any Codex/Boost config you carry over should match.
Debugging package resolution. When the package "isn't doing anything" in a host app:
php artisan about — confirm the provider is listed.php artisan vendor:publish --list — confirm your publish tags exist.php artisan config:clear && php artisan cache:clear — merged config is cached aggressively.composer dump-autoload — after renaming namespaces in a forked skeleton.composer why goodm4ven/anvil — when a dependency bump changes behaviour without a code change on your side.Extension points worth reusing. The genuinely valuable assets in an internal skeleton are usually: the base TestCase, the testbench.yaml workbench setup, the CI workflow, the Pint/PHPStan configs, and the agent guidelines. Copy those even if you throw away the provider and the namespace.
Documentation is effectively absent. Laravel Boost's search-docs tool will not return anything useful for this package — its docs index covers first-party and popular ecosystem packages. Read src/ and tests/ directly; the tests are the specification, and release notes are not.
Licence and attribution. MIT lets you copy freely, but keep the original copyright notice in a LICENSE or NOTICE file when vendoring significant portions into a commercial codebase — your legal review will ask.
How can I help you explore Laravel packages today?