Filament Skeleton Laravel Package

Getting Started

1. Install the package with Composer (composer require jordanpartridge/filament-skeleton) alongside a working Filament panel.
2. Publish any package assets before first use — look for a service provider boot() with publishes() calls, then run php artisan vendor:publish --tag=filament-skeleton-config (confirm the exact tag in the provider, it varies).
3. First place to look: the package's src/ directory for the Filament resource/page classes and any Commands/ folder, plus config/filament-skeleton.php if present. That tells you more about behaviour than the README.
4. First use case: scaffold one resource (or page) through the package's artisan command and inspect the generated file. Release 1.1 fixes auto-generation of the key, so as of 1.1 you should get a populated key without hand-editing — verify this on a single scaffold before running it across a project.

Because 1.1 is a single bugfix on top of 1.0, treat 1.0 docs and examples as current. Upgrade from 1.0 is a patch bump: composer update jordanpartridge/filament-skeleton.

Implementation Patterns

• Scaffold, then edit. Use the package to generate Filament classes/stubs, then own the output. Don't treat generated files as disposable unless you plan to re-run the command regularly.
• Generate keys deliberately. With 1.1's fix, keys are produced for you. Where the package writes keys into persisted models, run the generator in a seeder or migration path rather than relying on it at runtime, so backfills and tests behave the same way.
• Register generated resources explicitly. Filament 3+ discovers resources by directory, but if the skeleton outputs elsewhere, add the path in your panel provider's discoverResources().
• Stub overrides. If the package exposes publishable stubs, publish them once into your app and customise there. This is the cleanest extension point — it survives patch upgrades like 1.1 far better than editing vendor files.
• Pair with policies early. Scaffolded resources rarely ship with authorization. Generate the policy in the same PR as the resource so canViewAny/canCreate aren't an afterthought.
• CI guard. Add a smoke test that instantiates each generated resource/page class — cheap, and it catches scaffolding regressions when you bump the package.

Gotchas and Tips

• Key collisions. Auto-generation usually means a slug or random string. Check whether the strategy is uniqueness-checked against the DB. If it isn't, two scaffolds created in the same second can collide — assert uniqueness in your own code or use ULIDs.
• Existing records. The 1.1 fix only affects newly generated output. Rows created under 1.0 without keys will still be keyless; write a one-off backfill and confirm the column is nullable before you migrate.
• Regeneration loses edits. If the command overwrites files, back up or commit before re-running. Grep the command for file_put_contents/Filesystem::put without an existence check.
• Cache after upgrade. php artisan filament:cache-components and php artisan optimize:clear after bumping. Stale component caches are the usual cause of "my fix didn't apply".
• Version pinning. A one-line PR title for 1.1 means the package is young; pin to ^1.1 rather than * so a future minor doesn't silently change your generated keys.
• Debugging output. Dump the generated file to a temp path (--path flag if offered) and diff against a known-good scaffold when a key comes out empty or malformed.
• Extension points, in order of safety: publishable config → publishable stubs → subclassing the resource/page → vendor patching (avoid).