Google Spreadsheet Bundle Laravel Package

Technical Evaluation

Verdict: do not adopt. Use it as a pattern reference only. This is a zero-signal artifact — 0 stars, 0 dependents, score 0 — sitting on top of two layers that are both end-of-life. The TPM-relevant framing is that the pattern it enables (ops teams editing a sheet the app reads) is genuinely valuable; this dependency is not the way to get it.

Architecture fit

• Despite being filed under "Laravel/PHP," this is a Symfony2 bundle: a *Bundle class, a DependencyInjection/Extension, and a config tree intended for app/AppKernel.php. Laravel consumes Symfony components, not bundles, so it is not installable into a Laravel app in any meaningful sense. At best you vendor the underlying asimlqt/php-google-spreadsheet-client and re-wire it by hand — at which point the bundle contributes nothing.
• What the bundle actually delivers is DI wiring plus credential config plumbing. That is roughly 100–200 lines of glue, reproducible as a Laravel service provider and a thin adapter in under a day.

Integration feasibility — low

• The API it targets is retired. asimlqt/php-google-spreadsheet-client speaks the legacy Spreadsheets API (GData feeds, ClientLogin/OAuth1 bearer). Sheets API v4 is REST/JSON with OAuth2 and a different resource model (spreadsheet → sheet → range → value range). This is a rewrite, not a config change.
• The framework layer is EOL. Symfony 2.8 lost security support in November 2018. Any host app carries unrelated unremediated CVEs, so this cannot be the only inherited risk.
• Pinned google/apiclient will likely conflict. Versions of this vintage predate the Google_Client → Google\Client namespace migration and will not co-install with a current client without a fork.

Technical risk

Key questions to answer before any commitment

1. What is the job — export a report, read a sheet as a data source, or two-way sync with humans editing cells? The third is a product problem, not a library problem.
2. Which auth model — service account (server-to-server, default choice) or delegated user OAuth (only if per-user Drive access is a hard requirement)?
3. What data classification touches the sheet? A spreadsheet is an unmanaged data store; PII or financial data there is a compliance finding waiting to happen.
4. What are volume and latency expectations? Quota ceilings, not PHP, are the limit. If we need sub-second reads or large row counts per sync, the design is wrong regardless of client.
5. Is there an existing Sheets integration elsewhere in the org to standardize on?

Integration Approach

Stack fit

• On Laravel: reject the bundle outright. Use google/apiclient directly against Sheets API v4, wrapped behind an internal interface (e.g. SpreadsheetWriter::append(string $sheetId, array $row)). Evaluate a maintained wrapper such as revolution/laravel-google-sheets as optional sugar — the direct client is ~30 lines and keeps one fewer dependency inside the trust boundary.
• On a genuinely legacy Symfony 2 app: still don't adopt. Register google/apiclient v2 as a service in services.yml; that costs less time than debugging an abandoned bundle's auth flow.

Migration path

1. Spike (1 day). Service-account JSON key → google/apiclient → authenticate → read a range → append a row to a throwaway sheet. This proves the entire risk surface.
2. Abstract. Define the interface the domain actually needs (exportReport, syncRows). Nothing above it should know Sheets exists.
3. Implement. Sheets v4 adapter behind the interface. Choose valueInputOption=USER_ENTERED vs RAW deliberately — the wrong choice silently mangles dates and leading zeros.
4. Cut over. If a legacy path exists, dual-run and diff outputs before retiring it.
5. Decommission. Remove the bundle from composer.json, delete container/config entries, and confirm no credential params linger.

Compatibility

• Target PHP 8.1+ and google/apiclient ^2.x. Service account for server jobs; OAuth2 refresh-token flow only where per-user access is non-negotiable.
• Spreadsheet IDs and tab names live in config, not code — tab names are user-editable and will drift.

Sequencing

• Week 1, in parallel: the interface definition (cheap, independent) and the spike (proves auth, quota headroom, and write semantics).
• Commit to the full adapter only after the spike confirms quota headroom and the data-classification question is answered.
• Scope the first release as an export/reporting surface. Do not let a spreadsheet integration quietly become a system of record; promote it to a data source only with explicit review.

Operational Impact

Maintenance

• Upstream is abandoned: no releases, no triage, no dependents to absorb breakage. Adopting means owning a fork permanently — a standing cost with no offsetting benefit over the direct client.
• The replacement (google/apiclient) is Google-maintained, converting an unsupported dependency into a supported one at equal or lower complexity. This is the rare case where the safer option is also the cheaper one.

Support

• Zero stars and zero dependents means no Stack Overflow corpus, no issue history to search, and nobody to escalate to. Every incident is first-principles debugging. For a TPM this is the strongest single argument against adoption: the support cost is unbounded and unpriced, and it will surface as unplanned engineering time.

Scaling

• Quotas are the real ceiling: roughly 300 read requests/minute per project, 60 requests/minute per user per project, and a 10M-cell-per-spreadsheet limit. Design for batched reads (values.batchGet) and batched appends — never per-row calls in a loop.
• 429 and 5xx require exponential backoff with jitter. Without it, a nightly export fails intermittently and presents to stakeholders as a data bug.
• Sheets is a presentation layer, not storage. Anything needing joins, transactions, or history belongs in a real database and gets rendered to Sheets.

Failure modes to instrument from day one

• Auth failure — expired refresh token, revoked service account, or the target sheet not shared with the service-account email. Most common and least obvious break.
• Schema drift — a human inserts, deletes, or reorders columns; the writer keeps appending and produces silently misaligned rows. Validate headers on every run and fail loudly.
• Partial writes on large appends — Sheets can accept some rows and reject others; record what landed.
• Quota exhaustion cascading across tenants sharing one GCP project.
• Silent truncation of values exceeding cell limits.

Ramp-up

• Technical ramp for the replacement is low: a mid-level engineer ships the v4 spike in a day. The onboarding burden is organizational — creating the GCP project, a service account, a key-rotation policy, and sharing the target sheet with the service-account email. Budget a full day for access approvals; that is where schedules slip, not the code.
• Budget no ramp-up time for the bundle itself. There is nothing to learn that will still be usable in six months.

Recommendation: Reject asgoodasnu/google-spreadsheet-bundle. Fund a one-day spike against Sheets API v4 with google/apiclient, wrap it behind a domain interface, and size the work at roughly one engineer-week including quota handling, header validation, and instrumentation. Record the decision in the architecture log so the same package does not resurface in a future evaluation.