overtrue/laravel-skeleton
A ready-to-use Laravel application skeleton that ships with sensible defaults and commonly used packages preconfigured, so you can skip repetitive setup and start building your next project faster. Ideal for bootstrapping APIs and web apps with a clean, opinionated starting point.
Architecture fit. This is not a library you install; it is a full Laravel application skeleton distributed as a create-project template. That distinction dominates every other consideration: there is no adapter surface, no service provider to register, no seam to wire it into an existing codebase. Adoption means becoming the application, which makes it a fit only for greenfield work inside a Laravel-only organization — and even then it competes directly with the first-party laravel/laravel skeleton and the official starter kits, which carry the framework's own release cadence and support commitments.
Integration feasibility. Effectively zero for an existing product. A composer require is not the consumption model; you fork the repository, take ownership of every file, and thereafter diverge permanently. Any value must therefore be justified against the cost of owning the entire application foundation. Realistically the feasible integration is a pattern harvest: clone it into a sandbox, diff it against a clean laravel/laravel baseline, and lift the handful of configuration, middleware, or directory-convention decisions that are genuinely better than the default — discarding the rest.
Technical risk. High, concentrated in provenance and lifecycle. The repository is explicitly described as a personal skeleton ("for me"), maintained by a single author, with a last release of 2023-09-26 — which places its pinned Laravel version well behind current, and quite possibly on a branch that is past or near end-of-life for security fixes. The 139-star population implies a minimal user base, so there is no crowd-sourced bug-finding, no fork ecosystem, and no de facto support channel. Locked third-party dependencies are unknown and may include Chinese-ecosystem packages with locale, timezone, and documentation assumptions that are non-obvious to a Western team. There is no evidence of a maintained test suite or CI gate, and no semver contract applies to a skeleton anyway — every file is a breaking change waiting to happen.
Key questions.
zh_CN), timezone, currency, or naming conventions that would silently propagate into a Western deployment?laravel new does not — and are any of them actually better, or merely different?Stack fit. Binary. If the target is Laravel/PHP, it is technically runnable; if the target is anything else, it is irrelevant. Within Laravel, the fit is narrow: teams with an established internal starter kit gain nothing and lose consistency, while teams with no standard scaffolding should be evaluating the first-party skeleton first and treating this only as a comparison point.
Migration path. There is no migration path in the conventional sense — a skeleton cannot be introduced incrementally, and retrofitting an existing application onto it is a rewrite disguised as a migration. The only sane direction of travel is the reverse: adopt the skeleton only at project genesis, or extract individual patterns into an internal template you already control. Do not plan for upstream sync; after the first commit, the fork is yours.
Compatibility. Assume divergence from day one. Framework upgrades, PHP version bumps, and dependency patches all become internal work with no upstream to lean on. Pin the fork to a known-good Composer lock at inception and treat every subsequent composer update as a change that requires the same review rigor as production code, because it is.
Sequencing. (1) Clone and install in an isolated, disposable environment; capture install time, resolver warnings, and any failing post-install scripts. (2) Diff against a clean laravel/laravel at the same major version to produce a concrete inventory of what is actually added. (3) Score each delta on value-to-ownership-cost; expect the list to be short and the winners to be configuration-level. (4) Port only those deltas into an internal starter kit you own and test. (5) Archive the clone as reference and record the decision. Recommendation: harvest, do not adopt — the package's score of 2.165 with an opportunity score of 2.67 is consistent with this read: low as a foundation, mildly interesting as a source of ideas.
Maintenance. Total and permanent after fork. There is no merge stream, no CVE notification path, and no maintainer obligation to you or anyone. Your team becomes the sole maintainer of an entire application skeleton with an undocumented, single-author design rationale — the worst combination, because the code is legible while the reasoning behind it is not.
Support. Best-effort GitHub issues against a personal repository with a small audience and likely a Chinese-language issue backlog. No SLA, no vendor, no commercial backing. Budget for the possibility that questions go unanswered indefinitely.
Scaling. The skeleton itself does not constrain scale, but its defaults will. Skeleton defaults are optimized for developer experience, not production: expect synchronous queue drivers, file or database sessions and cache, loose logging configuration, and debug tooling enabled. Each of these is a predictable pre-production hardening item, and the risk is that they are inherited silently because the team assumes the template was production-grade.
Failure modes. The realistic failure is not a dramatic break — it is quiet drift. An unpatched framework version accumulates CVEs; stale transitive dependencies cause composer install to break months later when a package is yanked or a PHP minor version moves; locale and timezone defaults surface as subtle data-correctness bugs that are expensive to unwind post-launch. The structural failure is knowledge concentration: one engineer understands the inherited conventions, and no one else does.
Ramp-up. Low for anyone fluent in Laravel — it is standard Laravel with opinions layered on. The hidden cost is not learning the framework but reverse-engineering the author's intent, which is undocumented and, given the personal-skeleton framing, may never have been intended for a second reader. Onboarding an existing Laravel team to a first-party skeleton costs near zero; onboarding them to this one costs near zero plus an unbounded tail of "why is this here?"
How can I help you explore Laravel packages today?