Product Decisions This Supports
- Build vs. buy for in-app guidance (onboarding tours, feature callouts, "getting started" checklists). The package's implied scope is generic guided-tour scaffolding for a PHP web app. That is a real product surface — activation, feature discovery, time-to-first-value — so the category is worth a decision. This specific artifact does not inform that decision: the README is a single heading, there is no usage documentation, no configuration reference, no tests, and no release history visible.
- Dependency posture / supply-chain review. Archived status plus 0 stars and 0 dependents gives us a clean, low-ambiguity answer: not a dependency we can justify. That is a decision in itself — we can close the "evaluate endroid/guide-bundle" line item rather than carrying it in the backlog.
- Framework-fit triage. Endroid publishes Symfony bundles; this is a Symfony bundle, not a Laravel package. If our target is a Laravel codebase, the integration cost (service provider bridging, container/config translation, no
Illuminate conventions) is non-trivial and undocumented — this pushes the decision toward "not applicable" before feature scope is even considered.
- Roadmap de-prioritization of guided tours as a bought capability. With no maintained PHP-side option identified here, the realistic paths are (a) a client-side tour library (Shepherd.js, Driver.js, Intro.js, React Joyride) with our own persistence of tour state, or (b) a small in-house implementation. Either is a scoped, estimable piece of work rather than an integration.
- What it does not support: any estimate of effort, any API/extension-point design, any performance or multi-tenancy assessment, any evaluation of localization or accessibility of the tour UI. There is no artifact to review.
When to Consider This Package
Consider it only in narrow, low-stakes situations:
- You are auditing the broader
endroid/* Symfony bundle family for a Symfony application and want to confirm what this one covers before ruling it out.
- You need a reserved namespace/placeholder in a prototype and accept that you will own 100% of the code and maintenance.
- Your stack is Symfony (not Laravel), you have spare engineering capacity, and you are prepared to treat this as a fork-and-own starting point rather than a dependency.
Look elsewhere — in practice, always — when any of the following hold:
- You need support or security patches. Archived means read-only: no fixes, no compatibility updates with future PHP/Symfony/Laravel majors. That is an unbounded future liability for a user-facing surface.
- You need documentation to estimate work. There is none. Any estimate becomes a spike, and the spike may conclude "write it ourselves."
- You are on Laravel. Framework mismatch; the idiomatic Laravel answers are a Blade/Livewire component plus a JS tour library, or a maintained onboarding package, not a Symfony bundle.
- Community validation matters. Zero dependents and zero stars means no field-tested edge cases, no Stack Overflow corpus, no third-party integrations.
- You need accessibility, i18n, or analytics hooks on tours. Nothing here indicates any of these exist; you would be specifying them from scratch.
Recommended substitutes to evaluate against build cost: a maintained client-side tour library with your own state persistence, or a lightweight in-house onboarding service (tour definitions in config/DB, completion flags per user, an event emitted on completion so product analytics can measure activation lift).
How to Pitch It (Stakeholders)
Recommendation: no-go. Do not adopt endroid/guide-bundle.
The package is archived, undocumented (the README contains only its own title), has zero stars and zero dependents, and is a Symfony bundle rather than a Laravel package. License is MIT, so there is no legal obstacle — but there is also nothing to integrate. Adopting it would mean writing the entire capability ourselves inside a namespace no one maintains, while inheriting the expectation that we track upstream changes that will never arrive.
For executives: we evaluated a bought/borrowed option for in-app product tours and found no viable candidate here. The capability is still worth having — guided onboarding is a common lever on activation and feature adoption — so the ask is a small, time-boxed build: a config-driven tour definition plus per-user completion state on our side, rendered by a maintained open-source tour library in the browser, with a completion event wired into product analytics so we can measure whether tours actually move activation. Estimated as a contained piece of work, fully owned by us, with no abandoned-dependency risk.
For engineering: treat this repository as reference-only, if that. If someone wants a Symfony starting point, fork it explicitly and take ownership; otherwise stand up the tour definitions and persistence layer natively and pick a front-end library on maintenance signals (recent releases, open-issue responsiveness, accessibility support).