- How do I install xn/laravel-admin with Composer?
- The package is distributed as a bare GitLab repository rather than through Packagist, so you add a vcs repository entry pointing at https://gitlab.com/xn_workshop/laravel-admin in composer.json and then require xn/laravel-admin. Because access is repository-scoped, each consuming application needs GitLab credentials configured in auth.json or a Composer auth config, which adds token rotation to your operations. No tagged releases are surfaced, so pin the dependency to a specific commit or branch instead of a version range.
- Is xn/laravel-admin on Packagist and does it have tagged releases?
- No public Packagist listing is visible, so installation goes through a VCS repository entry or a private registry. That means there is no semantic versioning contract and no Composer provide or replace metadata to inspect from outside. Without tags you cannot constrain to a stable version, so record the exact commit you deploy and review changes before bumping it.
- Which Laravel and PHP versions does xn/laravel-admin support?
- The supported Laravel and PHP matrix is not documented publicly, so this has to be verified rather than assumed. Inspect the package composer.json require block and any CI configuration, then install it in a scratch Laravel application and run your own tests. Treat support for your current Laravel major and the next one you plan to adopt as a hard gate before any architecture discussion.
- What license does xn/laravel-admin use?
- No license file or composer.json license field is visible from outside the repository, so both internal use and redistribution are unresolved. Obtain read access and check for a LICENSE file before production use. An unknown license is usually a legal review blocker, and it is also a problem if you ever need to fork or redistribute the code.
- How is xn/laravel-admin different from Filament, Nova, Backpack, or z-song/laravel-admin?
- The package states no position relative to Filament, Laravel Nova, Backpack, Orchid, or the z-song/laravel-admin lineage, so it is unclear whether it is a bespoke internal panel, a thin wrapper, or a fork. Review the source tree and commit history to identify any upstream dependency and which commit it tracks. That determines your upgrade path and whether upstream security fixes reach you.
- Does xn/laravel-admin define its own auth guard and user model?
- Admin packages commonly register a guard, route group, middleware stack, and sometimes their own user model, and there is no external confirmation of what this one does. Review the service provider, published config, and migrations to see whether it owns authentication or composes with your existing guard. Admin routes are the highest-privilege surface in the application, so a weak authorization layer is a direct privilege-escalation path.
- Is xn/laravel-admin safe to run in production?
- There is no visible test suite, CI badge, or security disclosure policy, and zero dependents means no third-party field reports of defects or compatibility problems. That absence is not proof of poor quality, but it shifts the entire validation burden onto your team. Pin a reviewed commit, conduct a read-only code review of the service provider and authorization layer, and exercise it in staging before touching production.
- Does xn/laravel-admin have tests or a CI pipeline I can run?
- No public CI badge or test suite is advertised, so you cannot treat upstream tests as a quality signal. Install the package into a disposable Laravel app and write smoke tests around login, CRUD routes, and authorization checks. If the repository does contain tests, run them yourself against your exact Laravel and PHP versions.
- Can I use xn/laravel-admin in an API-first Laravel app with a separate SPA?
- If your application is API-first with a separate frontend, a Blade-rendered admin panel may simply be the wrong shape. Check whether the package requires Blade views plus Vite or npm asset compilation, which adds a second frontend build to your pipeline, and whether it assumes session-based auth rather than token or SSO. Those two constraints usually decide fit before any feature comparison.
- How should I evaluate and migrate to xn/laravel-admin, and is it maintained?
- Do not adopt it on a production application first. Establish who owns the repository and whether it is an active internal fork, a scaffold, or abandoned work, then run a read-only review of the service provider, routes, middleware, guard, and migrations. Install it in a throwaway Laravel app, then in staging behind your normal auth, pin the commit, and record the license status before any rollout decision.