Oneauth Laravel Package

Product Decisions This Supports

• Build vs. buy. A Composer-installable Laravel package is the cheapest kind of dependency to trial: one composer require, a published config file, and a service provider. For commodity concerns (auth scaffolding, media uploads, audit logging, PDF generation, payment webhooks), defaulting to adoption and spending engineering time on differentiated features is almost always the better trade. Reserve in-house builds for logic that is genuinely part of your product's moat.
• Roadmap sequencing and release-train planning. A package shipping a major version (v3.x) is asserting a stable API contract. Pinning to a major version lets you commit to a quarterly release cadence without re-architecting mid-cycle — that is a planning input, not just an engineering detail.
• Integration cost estimates. Laravel packages that follow framework conventions (Eloquent models, queue workers, Blade views, Artisan commands, migration publishing) collapse integration effort from weeks to days. That directly changes the cost side of a feature's business case.
• Use-case fit. Best suited to internal tooling, admin surfaces, back-office workflows, and integrations where the surrounding app is already Laravel-first. Poorly suited to anything requiring framework-agnostic portability or multi-runtime deployment.
• Scope validation for this release specifically. The v3.0.0 notes contain no feature list, no changelog, and no migration guidance. Treat this as an unvalidated spike candidate, not a roadmap dependency, until scope is documented.

When to Consider This Package

Consider it when:

• Your stack is Laravel/PHP and the package declares a supported Laravel version matrix you actually run.
• It is Composer-installable, semver-tagged, and has a real changelog across prior majors.
• The license is compatible with your distribution model (MIT/Apache vs. commercial/proprietary).
• Maintenance signals are healthy: recent commits, responsive issues, CI, and a security-advisory history you can inspect.
• The concern it covers is commodity — you would otherwise spend a sprint rebuilding it.

Look elsewhere when:

• The release notes are the only documentation available, as is the case here ("Initial version").
• A package advertises v3.0.0 but describes itself as an initial version. That is internally contradictory — a third major implies two prior majors, deprecations, and an upgrade path. Either the versioning is aspirational or the history has been dropped. Both are diligence blockers.
• No stated Laravel version support, no tests, no CI, or single-maintainer with no successor.
• It wraps a third-party API whose own breaking changes you cannot absorb on your schedule.
• You would be the first production adopter of an untested major.

Required diligence before adoption: Packagist download trends, GitHub issue response latency, open CVE/advisory history, and a spike PR that exercises the upgrade path from the prior major (if one exists).

How to Pitch It (Stakeholders)

For executives: This is a Composer package that drops into our existing Laravel application — no new infrastructure, no new vendor contract, no ops footprint. Integration cost is measured in days, not sprints, and the exit cost is low because it is a single dependency we can pin and remove. Recommendation: fund a timeboxed two-day evaluation spike, not a commitment. We should not put it on the roadmap until scope is documented.

For engineering: Evaluate it against a one-sprint in-house build. Confirm three things in the spike: (1) the config publish-and-override story — can we customize without forking; (2) the Laravel version support matrix against our current runtime; (3) the actual upgrade path, since v3.0.0 self-describes as an "initial version," which we should treat as a red flag until the release history is verified. Deliverable is a spike PR plus a one-page recommendation.

Headline risk: The release is labeled v3.0.0 but documented only as an initial version. Until that discrepancy is resolved and a feature list exists, this is an evaluation candidate only — do not pin it in a production dependency without a documented changelog and a maintenance signal.