- What is overtrue/laravel-skeleton and how is it different from a normal Composer package?
- It is a complete Laravel application skeleton distributed as a create-project template, not a library you add to an app. There is no service provider to register, no adapter surface, and no seam to wire into an existing codebase. Adopting it means becoming the application, so it only fits greenfield Laravel projects.
- How do I install overtrue/laravel-skeleton?
- You consume it like the official skeleton, using composer create-project overtrue/laravel-skeleton or by cloning the repository directly. A plain composer require is not the consumption model. Once you take it, you fork it and own every file in the application foundation.
- Can I add overtrue/laravel-skeleton to an existing Laravel application?
- No, integration feasibility into an existing product is effectively zero because a skeleton cannot be introduced incrementally. Retrofitting a running app onto it is a rewrite disguised as a migration. The realistic approach is a pattern harvest: clone it into a sandbox, diff it against a clean laravel/laravel baseline, and lift only the configuration or convention decisions that are genuinely better than the default.
- Which Laravel version does overtrue/laravel-skeleton target?
- The repository's last release dates to 2023-09-26, which places its pinned Laravel version well behind current and possibly on a branch that is past or near end-of-life for security fixes. Check composer.json for the exact pinned major and confirm whether that version still receives security patches, not just bug fixes. Treat the pinned version as a hard constraint on the project you start with it.
- Is overtrue/laravel-skeleton still actively maintained?
- It is explicitly a personal skeleton maintained by a single author, with a last release of 2023-09-26 and a small user base of roughly 139 stars. There is no fork ecosystem or crowd-sourced bug-finding to lean on, and no upstream support commitment. Plan to own the entire application foundation after your first commit rather than expecting upstream sync.
- Is overtrue/laravel-skeleton production ready?
- It can be runnable, but readiness depends entirely on the pinned Laravel version, the locked dependency tree, and whether you have audited every file you inherited. Because a skeleton carries no semver contract, every file is potentially a breaking change. Pin the fork to a known-good Composer lock at inception and review composer updates with the same rigor as production code.
- Does overtrue/laravel-skeleton ship a test suite and CI pipeline?
- There is no evidence of a maintained test suite or CI gate in the project. Verify this yourself by running the tests, if any, from a clean install before you commit to it. If coverage is missing, budget for building your own test harness and CI from scratch on top of the skeleton.
- What third-party dependencies and locale assumptions does overtrue/laravel-skeleton lock in?
- The full locked dependency tree is not documented here, and it may include Chinese-ecosystem packages with locale, timezone, currency, and documentation assumptions that are non-obvious to a Western team. Audit composer.lock and grep the configuration for zh_CN locale, timezone, and naming conventions before deploying. Any settings you keep will silently propagate into your application.
- How does overtrue/laravel-skeleton compare to laravel/laravel and the official starter kits?
- The first-party laravel/laravel skeleton and official starter kits carry the framework's own release cadence and support commitments, which this personal skeleton cannot match. Teams that already have an internal starter kit gain nothing here and risk losing consistency. Teams with no standard scaffolding should evaluate the first-party options first and treat this repository mainly as a comparison point.
- How do I upgrade Laravel or keep a forked overtrue/laravel-skeleton up to date?
- There is no upstream sync after your first commit, so framework upgrades, PHP version bumps, and dependency patches all become internal work. Lock the fork to a known-good composer.lock at inception and treat every composer update as a production change. Assume divergence from day one and plan to maintain the foundation yourself.