Weave Code
Quest Laravel Package
caneara/quest
Quest is a Laravel package for adding a lightweight quest and task system to your app. Define multi-step quests, track user progress, and reward completion through a simple, fluent API with ready-to-use models and migrations.
A pseudo fuzzy-searching library for Laravel database queries.
Frequently asked questions about Quest
- How do I install Quest in a Laravel application?
- Install Quest with composer require caneara/quest, publish its config file, add the HasQuests trait to the Eloquent model that should own progress, and define one or more Quest subclasses. The integration is container-resolved and does not require external services, queues, or mandatory migrations. Most of the work is domain modeling rather than plumbing.
- Which Laravel and PHP versions does Quest support?
- The package is described as fitting Laravel 9, 10, and 11 applications on PHP 8.1 and newer. However, the v4 release notes do not clearly document the supported version matrix, so check the composer.json constraints on the exact tag you install. A narrowed Laravel or PHP constraint is a common cause of surprise failures and may not appear in release notes.
- How do I define a multi-step quest in Quest?
- Create a Quest subclass that declares ordered steps and the allowed transitions between them, then attach the HasQuests trait to the Eloquent model whose state you want to track. Triggers drive state changes through a fluent API, making Quest a lightweight finite-state-machine layer rather than a full workflow engine. Keep quest graphs simple when first integrating.
- How does Quest track progress and reward completion?
- Progress is tracked by the state of the quest steps attached to your model, and completion rewards are handled through the package's fluent API. Because Quest is container-resolved and config-aware, you can wrap transitions in application services or events. Verify reward behavior against your app's domain rules before production rollout.
- What changed in Quest 4.0.0 and is it a breaking change?
- Version 4.0.0 is a major semver bump whose changelog is essentially a single PR titled Added configuration options. That is not enough to know whether the config work carried breaking changes or whether the major bump was applied loosely. Diff the v3.0.0...v4.0.0 tree and test transition semantics before adopting v4.
- How do I safely upgrade from Quest 3 to Quest 4?
- Pin existing services to ^3.0 first so a transitive composer update cannot pull v4 unannounced. Then open a spike branch, upgrade to ^4.0, publish the config, and compare every published default against your v3 assumptions. Run the existing workflow and state tests plus explicit tests for concurrent and invalid transitions, then canary one service.
- How do I publish and configure the Quest config file?
- Quest v4 moves behavior toward Laravel's standard config/quest.php plus vendor:publish convention, which lets you tune behavior per application. The key risk is whether the new config keys default to v3-equivalent behavior or silently change transition and trigger semantics. Document each key and its default, and treat any behavioral delta as a breaking change in your own upgrade notes.
- Does Quest work with Laravel events, queues, and transactions?
- Quest composes cleanly with Eloquent observers, domain events, queued jobs, and policy-based authorization. You can wrap transitions in database transactions and dispatch listeners without fighting the framework. No external services or queues are mandated by the package itself.
- How should I test Quest state transitions?
- Run your existing workflow and state test suite against the Quest version you plan to use. Add explicit tests for concurrent transitions, invalid transitions, and any custom Quest subclasses or overridden hooks. Confirm test coverage on the v4 tag, since the evaluation flags unknown test status for that release.
- Is Quest production-ready and well maintained?
- Treat Quest as a lightweight but single-maintainer dependency: bus factor is 1, and the only recent change was driven by a first-time contributor. For load-bearing workflows, consider vendoring or forking into an internal namespace, or at minimum document a contingency plan. If you need heavier guarantees, a dedicated workflow engine may be a better fit.
Weaver
How can I help you explore Laravel packages today?