- What is eveseat/web used for?
- eveseat/web is the Laravel web interface for SeAT, the EVE Online corporation and alliance management platform. It supplies the frontend views, layouts, navigation, menus, permissions, routes, middleware, and Blade/Vue assets that present character, corporation, and fleet data. It is the presentation tier of the SeAT platform rather than a standalone reusable library, so you adopt it as an application shell instead of composing it from components.
- Can I use eveseat/web in any Laravel application?
- No. The package assumes the sibling SeAT packages (eveseat/api, eveseat/services, eveseat/eveapi, eveseat/console) plus their database schema, permission model, and ESI integration. Fit is effectively binary: excellent for a SeAT instance or SeAT-compatible app, near-zero for a general Laravel product. Outside EVE Online tooling there is no reuse value.
- Which Laravel and PHP versions does eveseat/web support?
- The stack is PHP 8.x with Laravel, MySQL or MariaDB, Redis for cache and queues, and nginx. Because the package is tightly coupled to SeAT core, verify the composer.json constraints against your Laravel major and pin an explicit, tested version matrix across eveseat/web, eveseat/api, eveseat/services, and SeAT core. Partial upgrades can break silently, so lock Laravel within the supported range.
- How do I install eveseat/web?
- Install it with Composer, where the service provider is auto-discovered, then run vendor:publish for assets and config and build the frontend assets with Node or use the prebuilt ones. Installation alone is not adoption: you take on the SeAT deployment model, including migrations, queue workers, the scheduler, ESI SSO, and the permission model. The cleanest path is a greenfield SeAT deployment on a dedicated service, first validated end-to-end in a disposable sandbox with pinned versions.
- What license does eveseat/web use, and is GPL-2.0 safe for a commercial product?
- eveseat/web is licensed under GPL-2.0, which is copyleft. If your surrounding product is proprietary or distributed, modifications to this package can create source-disclosure obligations. Treat this as a product-boundary and licensing decision before any engineering work, because it can invalidate the whole plan.
- Which other SeAT packages does eveseat/web require?
- It bootstraps against eveseat/api, eveseat/services, eveseat/eveapi, and eveseat/console, and assumes SeAT core along with their schema and ESI token lifecycle. You cannot meaningfully install it alone, because the sibling packages supply the data, permissions, and API surface it presents.
- Does eveseat/web work without EVE ESI access?
- Not in practice. Character, corporation, and fleet data is gated on EVE ESI, and functionality depends on SSO and the ESI token lifecycle managed by the SeAT stack. ESI scope changes and outages are outside your control, so plan a fallback for when the API is unavailable or scopes shift.
- How should I integrate eveseat/web with an existing Laravel application?
- Do not embed it in-process inside an existing application. Run SeAT with eveseat/web as a bounded, separately deployed service and integrate over its HTTP and API surface. This isolates the upgrade blast radius and keeps the GPL boundary clean.
- How do I customize SeAT views, layouts, and navigation?
- Start with configuration only, since views, layouts, menus, and assets are published and configurable. If that is not sufficient, package your changes as a SeAT plugin before considering a maintained fork. Any UI customization beyond configuration pushes you toward a fork, which compounds both the licensing and upgrade problems.
- What ongoing maintenance does eveseat/web require?
- Plan for recurring work: tracking SeAT core and sibling package releases, rebuilding frontend assets on upgrade, running database migrations, and satisfying GPL source-distribution obligations for any modifications. The package has a narrow user base and small contributor pool, so bus-factor and long-term maintainability are real concerns. Assign a named internal owner and assume an ongoing maintenance allocation rather than a one-time install.