Builder Laravel Package

Technical Evaluation

Architecture fit — poor as named, useful as a pattern. Despite being evaluated in a Laravel/PHP slot, iter8/builder is a Silex service provider, not a Laravel package. Silex is a Pimple-container microframework that was abandoned in 2018 — the same year as this package's only release (2018-10-31). It does not ship a ServiceProvider, config publishing, or facades; it registers a builder into a Pimple container and hands off to PhpSpreadsheet or Spout. Adopting it in Laravel means writing an adapter shim around a dead container abstraction, which is strictly more work than writing the equivalent binding directly. The architectural value here is the idea — a thin, swappable writer abstraction over two spreadsheet engines — not the artifact.

Integration feasibility — low. Composer constraints are the first wall: a 2018 package will pin phpoffice/phpspreadsheet to a 1.x line and box/spout to 2.x (Spout was renamed to openspout/openspout and 2.x is EOL), and will almost certainly declare php: ^5.6 || ^7.0. Modern Laravel (10/11/12) requires PHP 8.1–8.2+, so dependency resolution will fail outright; a --ignore-platform-reqs install would drag in an unpatched PhpSpreadsheet with known CVEs. There is no evidence of CI, test coverage, or PHP 8 compatibility work.

Technical risk — high, and concentrated. Single maintainer, 1 star, 0 dependents, no release in ~7 years. Any defect is yours to fix. The two-engine switch also means two divergent behaviour surfaces (date handling, number formats, memory profile) that must be validated separately. Supply-chain exposure is real: pulling this in pins a transitive dependency tree that no longer receives security patches.

Key questions for the author/code review:

• Does the builder actually abstract the engines, or just factory-select one? What is the total surface area (likely < 300 LOC)?
• Which PhpSpreadsheet/Spout majors are pinned, and are there known CVEs in that range?
• Is there any test suite proving parity between the PhpSpreadsheet and Spout paths?
• What was the original driver — large exports (Spout, streaming) or rich formatting (PhpSpreadsheet)? That tells us whether the abstraction earns its keep.
• Is the MIT-licensed code clean enough to vendor and maintain as an internal fork?

Integration Approach

Stack fit: recommend not integrating as a dependency — harvest as reference. Laravel's ecosystem already solves this better: maatwebsite/excel (PhpSpreadsheet-backed, actively maintained, queue/chunk support) for feature-rich exports, and openspout/openspout for memory-safe streaming. Both are PHP 8-ready and have real support communities. The only scenario where iter8/builder wins is if a team genuinely needs runtime engine-switching behind one interface, which is rare and usually better satisfied by a SpreadsheetWriter interface with two adapters written in-house (~150 LOC).

Migration path (if the abstraction is deemed worth keeping):

1. Fork or vendor the source at 2018-10-31; snapshot it in the repo with the MIT notice retained.
2. Replace the Pimple/Silex registration with a Laravel ServiceProvider binding an interface to a concrete driver.
3. Re-point phpoffice/phpspreadsheet and box/spout → openspout/openspout at current majors; fix the resulting API breaks (the Spout→OpenSpout rename is not a drop-in).
4. Add a contract test suite asserting byte-level parity (or documented divergence) between drivers on a fixed fixture set.
5. Delete the Silex dependency entirely — nothing else should transitively pull it.

Compatibility: target PHP 8.2+, Laravel 11+, and treat every upstream major bump as an owned chore. Budget roughly 3–5 engineer-days for the fork-and-port, plus ongoing ownership.

Sequencing:

1. Day 1–2 — spike. Read the source. If the abstraction is thin, close the ticket and standardise on Laravel Excel + OpenSpout.
2. Day 3 — ADR. Record "build vs. fork vs. adopt" with the security posture as the deciding factor.
3. Week 1 — if forking: port, test, publish internally under a team-owned namespace (never as iter8/builder on Packagist).
4. Week 2 — pilot on the lowest-risk export (internal CSV/audit report) before touching customer-facing documents.

Operational Impact

Maintenance: Effectively 100% internal ownership from day one. Upstream is dormant; there will be no patches, no PHP 9 readiness, no CVE response. Treat the fork as first-party code with a named owner and a scheduled review each PHP/Laravel upgrade cycle.

Support: No community, no Stack Overflow corpus, no issue history to mine. Onboarding relies entirely on reading the source — cheap here because the codebase is small, but there is no external safety net when behaviour is surprising.

Scaling: Spreadsheet generation is memory- and CPU-bound, not request-bound. PhpSpreadsheet loads the whole workbook into memory (roughly 1–1.5 KB per cell); large exports will exhaust memory_limit well before they stress the app tier. Mitigations: force the streaming (OpenSpout) driver above a row threshold, chunk reads with cursor()/lazy(), write to temp files, and offload to a queue worker with its own memory ceiling. Horizontal scaling helps only if exports are asynchronous — otherwise a handful of concurrent large exports will pin workers.

Failure modes to instrument:

• Memory exhaustion mid-write → truncated/corrupt file delivered to a user. Enforce a row-count guard and fail fast with a clean 4xx.
• Temp-file leakage in storage/app when jobs are killed; add a scheduled sweeper.
• Formula/CSV injection (=, +, -, @ prefixes) on any user-supplied string written to a cell — a security issue the 2018 code almost certainly does not address.
• Locale/date-format drift between the two engines producing subtly different output per driver.
• Silent dependency pinning of an unpatched PhpSpreadsheet if someone forces the install.

Ramp-up: Low technical learning curve (small, plain-PHP surface) but high archaeology cost — engineers must reconstruct Silex idioms and infer intent without tests or docs. Estimate half a day to read and a day to port for a mid-level engineer; the real cost is the permanent ownership tax on a 1-star package solving a problem the framework already solves.

Recommendation: Do not adopt iter8/builder as a dependency. Score the opportunity as low (consistent with the 17.82 signal): the only defensible use is as a design reference or a vendored fork with a funded owner. Standardise on maatwebsite/excel plus openspout/openspout, and route any engine-switching requirement through an in-house interface.