Laravel Starter Kit Svelte Laravel Package

Technical Evaluation

Architecture fit. laravel-starter-kit-svelte is a scaffolding template, not a runtime library — the "integration" is a one-time code generation event, not a dependency you resolve at build time. That materially changes how a TPM should read this release: there is no semver upgrade path to manage, no transitive dependency surface introduced into your applications, and no ability for an upstream patch to break a running service. Architectural fit therefore reduces to opinion fit: does the template's auth stack, routing model (presumably Inertia + Svelte), test harness, linting, and CI defaults match the conventions we want to standardize on for new Laravel services?

What v1.0.1 actually changes. Two items, both housekeeping rather than capability:

• Removal of bloom configuration from the starter kits — a config-hygiene fix that eliminates dead or misleading configuration in generated projects. No functional regression is implied, but teams that scaffolded from v1.0.0 likely carry a vestigial bloom config block that should be deleted during their next cleanup pass.
• Dependency vetting plus a two-day hold on releases — this is a change to the publisher's release process, not to the artifact. It is a positive supply-chain signal and worth citing in a vendor-risk note, but it protects only the template's own dependency set. It does not vet the dependencies your generated application installs later.

Integration feasibility. High. Consumption is composer create-project / "Use this template" / manual diff, all of which are reversible and isolated to a throwaway branch or a scratch repo. Evaluation cost is measured in hours, not sprints.

Technical risk. Low for the patch; moderate at the package level. The package is at v1.0.x with a single visible maintainer and a first-time contributor on this release, there is no published backward-compatibility policy for the template's shape, and the underlying stack (Laravel majors, Svelte, Inertia) churns faster than a starter kit can absorb without breaking diffs. The dominant risk is not that upstream breaks us — it is that our fork silently drifts from upstream while we believe we are "on" the starter kit.

Key questions to resolve before adoption.

1. What is the supported matrix — PHP, Laravel, Node, Svelte, Inertia versions — and is it documented and CI-tested, or inferred from composer.json?
2. What was bloom (first-party Laravel package, internal tool, or third-party), and does its removal leave any generated project with a dangling service provider or env key?
3. What exactly does the two-day hold cover: direct dependencies only, or the full transitive tree? Is it enforced in CI or by convention?
4. Does the generated app ship with tests, static analysis (PHPStan/Larastan), Pint, and a working CI workflow — or just application code?
5. License and contribution terms; whether a fork-and-vendor model is anticipated by the maintainers.
6. Is there an upgrade/diff guide for consuming new template versions into already-scaffolded projects?

Integration Approach

Stack fit. Presupposes a Laravel/PHP 8.x+ backend with a Node build step and a Svelte frontend. Teams already running Inertia + a JS framework will find the shape familiar; teams standardized on Blade/Livewire will be adopting a second frontend paradigm and should treat that as an org-level decision, not a per-project one. The Node toolchain means CI runners need npm caching and a build stage — trivial, but it must be in the golden pipeline before the first service ships.

Migration path. For greenfield services: scaffold directly. For existing applications: do not port wholesale — treat the repository as a reference implementation and cherry-pick (auth flows, layout components, tooling configs, CI YAML) against your current conventions. A wholesale copy into a mature app imports opinions you did not evaluate.

Compatibility. Pin a commit SHA, not a tag or branch. Starter kits are re-shaped rather than upgraded; treating v1.0.1 as a version you "stay current on" is the wrong mental model. Record the pinned SHA and the date in an ADR so future maintainers know what the baseline was.

Sequencing.

1. Generate a project from the v1.0.1 SHA in a throwaway repo; run install, build, test, lint end to end.
2. Verify it builds on our CI, not the maintainer's, including the Node/Svelte step.
3. Diff the generated tree against our current service conventions; list every divergence and decide keep/replace per item.
4. Pilot one low-risk internal service.
5. Internalize: fork or vendor the pinned commit into an org-owned template repo where we control dependency pins, add our own dependency-update automation, and apply our own hold policy. This is the step that actually retires the upstream dependency.
6. Set a re-scaffold cadence — realistically once per Laravel major — and a named owner.

Operational Impact

Maintenance. Post-generation maintenance is entirely ours; upstream upkeep matters only until step 5 completes. The real ongoing cost is drift: N services scaffolded at different SHAs with no shared upgrade mechanism. Budget for a template owner and a periodic reconciliation pass, or accept that services will diverge and stop calling it a standard.

Support. GitHub-issue-level, small maintainer base, no SLA, no commercial backing evident. Acceptable for a template; unacceptable as a dependency for anything with an uptime commitment — which, again, a starter kit should never be.

Scaling. No runtime scaling characteristics to assess. Scales by replication of the pattern; the constraints are organizational (how many teams can hold the same conventions) and pipeline-level (Node build time per service, cache hit rates).

Failure modes.

• Upstream abandonment or repo/tag deletion — mitigated by vendoring the pinned commit internally, not by watching the repo.
• Silent drift across scaffolded services, discovered only at audit time.
• Framework churn: a Svelte or Inertia major forces a re-scaffold rather than a patch; plan it as planned work, not incidental.
• Supply-chain exposure in generated projects' dependency trees — the publisher's two-day hold is a good precedent but does not transfer; our own update policy must cover the post-generation graph.
• Residual bloom config in v1.0.0-derived repos: cosmetic, but it will generate support questions; add it to the cleanup checklist.
• Misreading the release as a version bump to track — leading teams to expect upgrade paths that do not exist.

Ramp-up. Low for Laravel developers already comfortable with Inertia; roughly one to two weeks for a React/Vue-fluent team new to Svelte's reactivity and component model. The larger ramp is organizational: the internalized fork's conventions become a thing people must learn, and that onboarding material has to be written and owned by someone.