Weave Code
Root Laravel Package
conedevelopment/root
A Laravel package by Cone Development that provides foundational utilities and conventions to streamline application development. Root helps organize code and reduce boilerplate, offering a lightweight base for building and extending Laravel projects.
Root is an admin package for Laravel applications.
Frequently asked questions about Root
- What is the Cone Development Root package for Laravel?
- Root is an admin package for Laravel applications from Cone Development. It installs as a Composer dependency, registers a service provider, and layers an admin surface such as routes, controllers, views and assets on top of an existing application, along with foundational utilities and conventions. It fits best in a standard Laravel monolith where the team wants CRUD-oriented back office screens without building them from scratch.
- Which Laravel and PHP versions does Root support?
- Check the package's composer.json and its Packagist page for the php and laravel/framework constraints before committing, then resolve it against your pinned versions. If resolution fails, run composer why-not conedevelopment/root to see the exact conflict. No formal upgrade or support policy is documented, so treat major Laravel upgrades as your own responsibility and test them explicitly.
- How do I install Root in an existing Laravel application?
- Require the package with Composer, then publish its config and assets, wire an admin authentication guard plus a role or permission gate, seed an admin user, and define your resources. The mechanical install is straightforward; the real question is whether it yields to your authorization model, route and middleware conventions, and deployment pipeline. A one-sprint proof of concept on a single read-only resource answers that empirically.
- Does Root handle authentication, routes, and middleware itself or use my existing setup?
- This is one of the key questions to answer during evaluation, because an admin package may own authentication and middleware or layer onto yours. Either way, isolate it behind a dedicated route prefix and middleware group, and commit its config file to your repository. Confirm the behavior in a proof of concept before rolling it out beyond a pilot module.
- What frontend stack does Root assume, and do I need a Node build step?
- The frontend approach matters because whether the admin is Blade, Livewire, or Inertia and Vue determines who on your team can extend it. Also confirm whether assets ship prebuilt or require a Node build step in your CI and container image. Opinionated admin packages create UI lock-in, so treat this as a decision criterion rather than an implementation detail.
- How does Root enforce authorization for each admin resource?
- How policies and gates are applied per resource is an open question that should be verified against your existing authorization model. Plan to map your policies onto package resources and keep domain logic out of the admin layer. Test with a low-privilege user and with a user who has no admin role at all before going live.
- What database tables and migrations does Root introduce?
- An admin package typically ships migrations, so review the schema footprint before installing on an existing database. Check whether table prefixes or isolation are configurable so it does not collide with your own tables. Publish and commit the migrations so schema changes are reviewed like any other code.
- Is Root a good alternative to Filament or Laravel Nova?
- Root is MIT licensed with zero license cost and a smaller surface, while Filament offers a much larger ecosystem and Nova is commercial with vendor support. The tradeoff is bus factor and self-support risk: a small adoption base means thin community answers and fewer battle-tested edge cases. Root is a reasonable low-commitment choice for a small internal CRUD tool, but if the admin surface is strategic and long-lived, ecosystem size should probably outweigh ergonomics.
- Is Root production-ready, and what are the main risks?
- The dominant risk is maturity rather than code quality: a very small adoption base implies a single-vendor bus factor and no visible security disclosure process for a package that sits behind authentication with write access to production data. Check test coverage, CI status, release cadence over the last twelve months, and open-issue age. Then isolate the package with its own route prefix and middleware group, run it in parallel behind a feature flag, and define the exit ramp on day one.
- Can I extend Root with custom fields, actions, filters, and non-CRUD screens?
- The documented extension path is a key question, because an undocumented extension model can force you to fork the package. Prototype one custom field, one custom action, and one non-CRUD screen before committing to the package. Keep customizations outside vendor code wherever possible so upgrades stay cheap and removal means deleting routes and tables rather than untangling business logic.
Weaver
How can I help you explore Laravel packages today?