- Is splash/staci on Packagist, and how do I install it in a Laravel app?
- There is no public evidence that splash/staci is published to Packagist; the project lives on GitLab with zero stars and zero dependents, so assume a VCS or path repository is required. Add a repositories entry pointing at the GitLab URL or an internal mirror, then run composer require splash/staci and confirm Laravel package discovery registers the service provider. Pin the connector and Splash core together by commit SHA rather than tracking a branch, because the two tend to version in lockstep. Verify the license during the same step, since supply-chain review is expected for an unpinned, low-visibility dependency.
- Which PHP and Laravel versions does splash/staci support?
- The supported PHP, Laravel, and Splash core constraints are not documented in what is publicly visible, so treat them as unknown until you check composer.json. Run a dependency resolution spike against your actual PHP version and Laravel major before committing any work to the package. If the constraints conflict, mirror the repository into an internal namespace, relax the constraint, run its test suite, and pin the result by commit SHA. A Laravel major upgrade is a realistic breakage point, so re-run the spike at every major bump.
- Is splash/staci production ready and actively maintained?
- Treat it as an unproven artifact: a single maintainer on a GitLab project with no release cadence, no issue history, and no downstream dependents, which is a bus factor of one. That does not rule it out, but it does mean no community to fall back on when something breaks. It is reasonable for internal batch ETL and scheduled imports behind an adapter, and a poor choice for user-facing request paths. Pilot one non-critical, idempotent dataset for two weeks and survive one dependency bump before productionizing.
- What does the Embedded designation mean for the splash/staci connector?
- Embedded means the connector runs in-process inside your PHP workers rather than proxying to a separate service or SDK daemon. That makes it a strong fit for batch and CLI ETL, scheduled imports, and queued jobs in a Laravel app, and a weak fit for low-latency request-path reads or independent scaling of the source. The practical upside is a flat deployment surface with no sidecar, no extra credential broker, and no new infrastructure beyond what STACI itself needs. Treat it as a data-extraction adapter, not a runtime dependency for user traffic.
- How do I run splash/staci from a Laravel queue worker or the scheduler?
- Invoke the Splash pipeline from a console command or a queued job and use splash/staci as the extract step of that pipeline. Keep the pipeline wiring in your infrastructure layer so Splash and STACI types never reach your domain code. Bind your adapter in a service provider, schedule the command, and attach row-count and freshness assertions so a silent no-op import is caught quickly.
- How do I stop splash/staci types from leaking into my domain code?
- Define an internal reader interface in your own namespace, implement it with a thin adapter over the package, and bind it in a service provider. If the package is abandoned, swapping to a hand-rolled HTTP client or an exported CSV becomes a one-class change instead of a refactor. This seam also gives you a clean place to hang fixture-based contract tests so upstream breakage fails CI rather than production.
- Does splash/staci stream results or buffer full result sets in memory?
- This behavior is not documented in what is publicly visible, so measure it rather than assume. Run one small dataset end to end in a sandbox branch and record a memory profile alongside the connector's failure and retry behavior on a malformed response. If it buffers full result sets, chunk your imports or page the source before scheduling anything large. Assume buffering until the spike proves otherwise.
- How do I test a Laravel pipeline that depends on splash/staci?
- Add a CI job that runs the package's own tests against your pinned commit, and write fixture-based contract tests behind your adapter interface. Use a small, deterministic dataset so the whole pipeline can be asserted end to end, including the failure path you recorded during the spike. That way an upstream commit that changes behavior fails the build instead of quietly corrupting a scheduled import.
- What are the alternatives to splash/staci?
- If STACI is reachable over HTTP, a hand-rolled client or an exported CSV import can replace the connector, and both are one-class changes if you isolate it behind an adapter. For static HTML output, route caching and Laravel-friendly static site generators cover similar ground. The main argument for splash/staci is that an embedded connector adds no infrastructure to your deployment, so weigh that against the maintenance risk of an unproven dependency.
- Does splash/staci generate static HTML for my Laravel routes and Blade views?
- The repository is positioned as an embedded Splash connector, so its documented architectural role is data extraction inside a pipeline rather than a full static site generator. If your goal is caching Blade-rendered pages as static HTML, confirm that behavior in a sandbox spike before designing around it. Keep the output behind your own interface either way, so you can swap in route caching or another static generation approach without touching application code.