Weave Code
Skeleton Laravel Package
laravel-frontend-presets/skeleton
A starter skeleton for creating custom Laravel frontend presets. It provides the package structure and boilerplate needed to build and install your own preset, making it easier to replace Laravel’s default frontend scaffolding with a tailored setup.
Laravel 5.5.x Front-end preset for skeleton
Frequently asked questions about Skeleton
- What is laravel-frontend-presets/skeleton used for?
- It is a starter skeleton for authoring your own Laravel frontend preset. It ships the package structure and boilerplate, including a preset service provider and a preset command that copies stub files onto a fresh Laravel application. You use it as a template to fork and tailor, not as a runtime dependency in a production app.
- Which Laravel versions does this preset skeleton support?
- It targets Laravel 5.5.x and the php artisan preset extension point that existed through Laravel 5.5 to 5.8. That extension point was removed in Laravel 6, so the package has no slot to plug into on modern Laravel lines. On Laravel 6 and above you should use laravel/ui, Breeze, Jetstream, or the official starter kits instead.
- How do I install laravel-frontend-presets/skeleton?
- The intended workflow is to fork or clone the repository, rename the vendor namespace and package name, then require it via a Composer path repository or your internal registry. Once registered, the preset command is invoked with php artisan preset <name> against a fresh Laravel application. It is a developer-workstation tool invoked once per project rather than a library you ship.
- How do I create my own frontend preset from this skeleton?
- Fork the repo, rename the namespace and service provider, strip out the demo preset, and substitute your own stubs for webpack.mix.js, package.json, assets, and auth views. Re-register the provider, publish it internally, and validate on a throwaway Laravel install. A competent Laravel engineer typically reaches a first working internal preset in two to five days.
- Does applying a preset overwrite existing files in my Laravel app?
- Yes. Preset application copies stubs over webpack.mix.js, package.json, frontend assets, and auth views, and there is no dry-run or rollback built in. That makes it a workflow hazard rather than a production concern, since it runs only on a fresh application at setup time. Always apply presets to a clean install or a committed branch you can revert.
- Does this package support PHP 8 and Composer 2?
- The code is PHP 7-era and PHP 8 compatibility is not verified, so expect to modernize dependencies and syntax before first use. Composer 2 generally works, but you should pin and test your forked version. Verify compatibility on your target PHP version before rolling the preset out to a team.
- Is this package safe to use in production?
- Nothing in it runs in a request cycle, so it never ships to production or adds a transitive dependency surface. The risk is confined to the developer workstation and to the accuracy of the stubs you copy in. Review every file in the fork, since you own it the moment you adopt it.
- Is laravel-frontend-presets/skeleton actively maintained?
- It is a low-activity template with roughly 13 stars, 0 dependents, and no downstream consumers to surface regressions. Adoption means becoming the maintainer of your fork from day one, with no upstream to pull fixes from. Budget that ownership as a permanent line item and set an explicit deprecation date tied to your Laravel upgrade roadmap.
- What are the alternatives to building a custom Laravel frontend preset?
- For modern Laravel, use the official starter kits, Breeze, Jetstream, or laravel/ui depending on your stack. If the real goal is fast, consistent new-project setup rather than a reusable preset, Composer create-project templates or a documented setup checklist are cheaper and longer-lived. A preset only pays back where greenfield creation is recurring, such as agency delivery or a multi-tenant product line.
- Should I adopt this package or treat it as reference material?
- Treat it as source material for a capability you build rather than a dependency to vet. First confirm whether any of your fleet still runs Laravel 5.5 to 5.8 and invokes php artisan preset; if not, the artifact is archival and its architectural value is zero regardless of code quality. If you do fork it, name an owning individual and team and document the fork's obsolescence date.
Weaver
How can I help you explore Laravel packages today?