Laravel Starter Kit Laravel Package

Technical Evaluation

Architecture fit

The core architectural fact is unchanged: this is a template, not a library. You clone/fork it and it becomes your application. There is no upgrade stream, no dependency boundary, and no vendor-consumer relationship to manage.

What 3.0.0 adds is concrete visibility into the stack it scaffolds, and it is older than assumed:

• Laravel 8.83.x — not the Laravel 10/11-era conventions I previously guessed. The dependabot stream stops at laravel/framework 8.83.27, and facade/ignition, laravel/ui 3.x, and laravel/breeze 1.x are all Laravel-8-era artifacts. Laravel 8 has been out of security support since January 2023.
• Frontend: Inertia + Breeze + Ziggy + Laravel Mix + Tailwind/DaisyUI. Mix (not Vite) is another Laravel-8-era marker.
• Actions pattern: lorisleiva/laravel-actions is present, so business logic is organized as action classes rather than services — a convention you will either adopt or spend time unwinding.
• One genuinely consumable piece: salla/ouath2-merchant (note the misspelling — "ouath") is a real, versioned Composer package carrying the OAuth handshake, bumped 1.0.0 → 1.4.0. That means the OAuth client is separable from the template; the routes, webhook receiver, and token model are not.

Net fit: still strong for greenfielding a small Salla merchant app, still weak for bolting onto an existing platform — but the calculus has shifted, because adopting the template now means adopting an unsupported framework on day one.

Integration feasibility

Materially lower than the previous assessment. The kit is three Laravel majors behind. Any build of consequence requires a framework upgrade before you write a line of product code, which removes most of the "working install flow in a week" advantage — you will spend that week upgrading PHP/Laravel, migrating Breeze/Mix to Vite, and replacing Ignition.

The better framing now: read it, don't fork it. If OAuth is the hard part, evaluate salla/ouath2-merchant as a direct dependency against your own Laravel version. A webhook receiver with signature validation and idempotency is a few hundred lines of work you should own anyway.

Technical risk

1. End-of-life framework (now highest). Laravel 8 receives no security patches. Shipping it is not a defensible position, so the fork carries an unavoidable upgrade project with no upstream to rebase onto.
2. Dependency pins may still be vulnerable. The bumps are a mix of routine and CVE-driven, and at least one looks like it stops short: guzzlehttp/guzzle lands at 7.4.4, which predates the fixes in 7.4.5 for the 2022 Guzzle advisories. axios 0.27.2 also predates later advisories. Verify each pin against the advisory database rather than trusting the bump.
3. Fork divergence — unchanged and now compounded, because upstream is diverging from a dead framework base rather than tracking a supported one.
4. Release hygiene. A 3.0.0 containing only dependency bumps and README edits is not semantic versioning; it signals version numbers that carry no compatibility contract. The changelog is also truncated mid-line. Dependabot PRs were batched into a single "Merging all dependabot deps" pull request — maintenance is sporadic and swept up periodically, not continuous.
5. No evidence of the things that matter. Twenty-plus months of release notes contain zero mention of webhook signature validation, idempotency, token-refresh hardening, uninstall handling, or test coverage. My prior open questions are not merely unanswered — the release history suggests they are not on the maintainer's roadmap.
6. Salla API version churn. Unchanged. Confirm what the 3.0.0 major actually signifies for API version targeting; the notes don't say.
7. Evidence limitation. This revision is derived from release notes alone; repository metadata (stars, dependents, release dates) was not supplied and prior figures should be re-verified before being cited.

Key questions to resolve before committing

• Is 3.0.0 a breaking change in any functional sense, or purely a dependency sweep? The changelog does not establish this.
• Is there a branch or roadmap targeting Laravel 10/11/12? If not, the template is effectively archived in spirit.
• Is salla/ouath2-merchant published on Packagist, under what license, and does it constrain Laravel/PHP versions independently of the template?
• Does the misspelled package name exist upstream, or does it resolve only via a repository override? This affects whether it can be a real dependency.
• Which Salla API version does the client target, and does it support Easy Mode, Custom Mode, or both?
• Is webhook signature validation implemented and tested? Is ingestion queued or synchronous?
• Is there any idempotency/dedupe story for webhook events?
• Is token storage encrypted at rest, with per-store isolation verified?
• Are the guzzle 7.4.4 and axios 0.27.2 pins on patched or vulnerable versions?
• What test coverage exists, and does CI run green on the 3.0.0 tag itself?
• Is there a Salla dev store we can point this at this sprint?

Integration Approach

Stack fit

PHP 8.0/8.1-era, Laravel 8, MySQL/Postgres, Redis queues, Inertia frontend built with Laravel Mix and DaisyUI. If your shop is already on Laravel 10/11 with Vite and Livewire or a separate SPA, the fit is now backend patterns only — cherry-pick, do not fork. If you are greenfielding and genuinely have no framework opinion, the fork is still viable, but only with the framework upgrade explicitly scoped and staffed as part of the initial work rather than discovered later. Still a hard no for non-PHP teams.

Migration path

1. Read before deciding. Timebox a review of the repo against your own architecture. The changelog alone is enough to rule out wholesale adoption for anything with a life beyond a prototype.
2. Evaluate salla/ouath2-merchant standalone. If it is a legitimate, versioned package, it may deliver most of the template's durable value — the OAuth handshake — without the fork. This is the single highest-leverage decision in the assessment.
3. Rebuild the thin parts yourself. Webhook receiver with signature verification, idempotency keys, token storage/refresh, uninstall handler, and a typed API client. This is bounded work, it lands on a supported framework, and you own it outright.
4. Fork only if the demo value is urgent — and if you do, treat the Laravel upgrade as the first ticket, not a later one.
5. Harden before feature work: secrets management, async webhook ingestion with backpressure, dedupe store, structured logging, health checks, alerting on token-refresh failure and queue depth.
6. Pin and track. Record the framework and dependency constraints on the upgrade board either way, and re-check the guzzle/axios pins against advisories.

Compatibility

Explicitly reconcile against your supported PHP/Laravel matrix — this is now the gating item, not a footnote. Retrofitting multi-tenancy and your auth/SSO into a single-store scaffold remains expensive and is unchanged.

Sequencing

Read-and-decide spike (1–2 dev-days) → salla/ouath2-merchant viability check (1–2 days) → fork-vs-build call → if forking, framework upgrade sprint → hardening → feature build → marketplace submission. Budget real time for Salla app review; it sits outside your control and is the schedule risk most likely to be underestimated.

Operational Impact

Maintenance

Ownership remains 100%, but the profile has worsened: you cannot "re-diff against upstream" into a supported framework, because upstream is not tracking one. Budget the framework upgrade as upfront capital plus 1–2 engineer-days per quarter for drift. Add an explicit periodic review of the dependency pins against security advisories, since that appears to be exactly the maintenance upstream is doing — occasionally and in batches.

Support

Unchanged: Salla developer docs and developer support for platform questions; no commercial support for the kit; community too small to rely on. Internally, set the expectation clearly — this is internally-owned software with a vendor-authored starting point, and the vendor-authored starting point is now dated. Code escalation is yours.

Scaling

Standard Laravel horizontal scaling applies; the durable concern remains the queue. Webhook traffic is bursty and correlated with merchant campaign activity, so ingestion must be async with backpressure. Per-store rate limits against the Salla API remain the trap — a naive retry loop will exhaust them.

Failure modes to instrument for

• Running an unsupported framework — no security patches, and an upgrade you owe the moment you ship.
• A dependency pin that looks bumped but isn't patched — verify guzzle 7.4.4 and axios 0.27.2 against advisories.
• Expired or revoked refresh tokens producing silent 401s and stalled syncs.
• Signature validation misconfigured → rejecting legitimate events or accepting spoofed ones. Both severe; test both directions.
• Missing idempotency → duplicate order/refund/shipment processing during webhook retries.
• Uninstall not handled → orphaned tokens, continued outbound calls, compliance exposure.
• Queue backlog during traffic spikes → delayed merchant-visible state.

Ramp-up

A Laravel-fluent engineer is productive on the code in 1–2 days, needs ~1 day on Salla domain concepts, and — new — needs 3–5 days on the framework upgrade if you fork. A strong engineer without Laravel experience is still 1–2 weeks, and the upgrade work makes the absence of a Laravel-native on the team more costly than before.

Verdict for planning purposes (revised): the first-party alignment is still real value, but 3.0.0 is a dependency sweep on an end-of-life framework, not a capability release. Downgrade from "worth a timeboxed spike as a build accelerator" to "worth a short read as a reference, plus a serious look at salla/ouath2-merchant as a standalone dependency." Do not fork this onto a supported-framework roadmap without scoping the upgrade first, and do not treat the low adoption as the disqualifier — the EOL base is the disqualifier.