Opentbs Bundle Laravel Package

Technical Evaluation

What the package actually is

mbence/opentbs-bundle is a thin Symfony bundle wrapper around OpenTBS (the TinyButStrong add-on that generates OpenDocument and Office Open XML files by merging data into .docx/.xlsx/.odt/.ods templates). The bundle's value-add is Symfony-specific: bundle registration, DI service definitions, and a config tree for pointing at template directories. The document-generation logic lives entirely in the upstream OpenTBS/TinyButStrong PHP library.

Architecture fit — poor, for two independent reasons

1. Framework mismatch. The package is a Symfony Bundle, not a Laravel package. It has no service provider, no facade, no publishable config, and no Laravel-style autodiscovery. Symfony bundles register through Bundle::class + DependencyInjection/Extension + config tree processing; none of that machinery exists in Laravel. Installing it in a Laravel app yields a class that nothing will ever boot.
2. Wrapper mismatch. Even if we shimmed the bundle, we would be adopting Symfony's integration opinions (hardcoded service IDs, Symfony KernelInterface coupling) purely to reach a library we could require directly.

The honest framing for the business: the package is not the asset — the underlying OpenTBS engine is. The bundle is ~a few hundred lines of glue whose only meaningful content is the config-to-service wiring we would rewrite anyway.

Integration feasibility — viable only via the underlying library

• Requiring OpenTBS/TinyButStrong directly through Composer and wrapping it in a small Laravel service provider is a half-day of work and removes the Symfony dependency entirely.
• The generation model (template file in → populated file out) fits cleanly behind a queued job and a Storage disk abstraction, which is a better fit for Laravel than the bundle's filesystem assumptions.
• Block/field templating syntax (TBS [var], [b.block], [onshow]) is data-driven, so templates can be owned by business users rather than developers — that's the real product value and it survives regardless of which wrapper we use.

Technical risk — high and asymmetric

• Archived, last release 2016-09-13. No upstream patches for 9+ years. Any CVE in the XML/ZIP handling path is ours to fix.
• PHP 5.x-era code. Expect deprecation noise and outright breakage on PHP 8.x (dynamic properties, each(), curly-brace string offsets, implicit nullable params). Compatibility work is unavoidable and unowned.
• Unvalidated by the ecosystem. 26 stars, 0 dependents. There is no community to inherit an integration pattern from and no signal that anyone runs this in production at scale.
• Untrusted-input surface. Document generation means parsing ZIP containers and XML from files that may be user-uploaded templates. Older libxml configuration raises XXE, zip-bomb, and entity-expansion concerns that must be mitigated at the boundary, not trusted to the library.
• License needs verification before adoption — TinyButStrong/OpenTBS carry LGPL-family terms that have distribution implications if we ship generated-document functionality in a closed-source product.

Key questions for the team

• Do we need any wrapper, or is a 100-line internal service class the correct scope?
• Are we standardizing on .docx/.xlsx, or do LibreOffice .odt outputs matter to the business? (This determines whether OpenTBS is even the right engine.)
• Who authors templates — engineers or business ops — and what's the review/versioning workflow for a template file that is effectively source code?
• Do we need PDF output too? OpenTBS does not do PDF; that's a second dependency (headless LibreOffice or a commercial renderer) and materially changes the architecture.
• Is phpoffice/phpword + phpspreadsheet a better-supported alternative for our specific document types, at the cost of losing the "business users edit templates" property?

Integration Approach

Stack fit

Zero direct fit. Adopting the bundle as-is would import a Symfony kernel contract into a Laravel application. The correct pattern is:

• composer require the upstream OpenTBS/TinyButStrong library only — do not install the bundle.
• A single OpenTbsServiceProvider registering a singleton DocumentGenerator bound to config (config/documents.php for template paths, temp dir, engine options).
• A DocumentGenerator contract with one obvious method: render(string $template, array $data, string $disk, string $path): string.
• All I/O through Laravel's Storage facade; all generation off the request thread via a queued job.

Migration path

1. Week 1 — proof of concept. One real business document (invoice or report), one template, generated inside a queued job, asserted against a golden-file fixture. This is where we learn whether the PHP 8 compatibility work is a day or a sprint.
2. Week 2 — hardening. Vendor the engine into our own namespace (or pin with a lockfile + a documented fork point), patch PHP 8 deprecations, add an input-sanitization layer for uploaded templates (libxml entity loading disabled, ZIP size/entry-count caps, temp-dir isolation).
3. Week 3 — integrate. Wire the generator into the domain service that owns the document, add golden-file regression tests to CI so template edits can't silently break output.
4. Ongoing — template ownership handoff to the business team, with a documented syntax guide and a template test harness.

Compatibility

• Engine is PHP-version-fragile; pin the interpreter range and treat any PHP upgrade as requiring a document-generation regression run.
• No Laravel version coupling beyond the framework's service-container and filesystem APIs, which are stable — the risk is entirely PHP-runtime, not framework-runtime.
• Document format compatibility with modern Word/Excel must be spot-checked; the engine predates recent OOXML revisions.

Sequencing

Do the PoC before committing to the engine. If PHP 8 remediation exceeds ~3 days, fall back to phpoffice/phpword + phpspreadsheet or to a headless-LibreOffice template pipeline, and treat the "business users own templates" requirement as negotiable rather than assumed.

Operational Impact

Maintenance

This is a fork-and-own dependency, not a consume-and-upgrade one. Budget:

• A named owner for the vendored engine and a documented patch log.
• A PHP-upgrade runbook that includes a full document-generation regression suite (golden files per template).
• An annual review to decide build-vs-buy again — the maintenance burden is permanent and does not decay.

The one genuinely positive operational property: OpenTBS is a self-contained PHP library with no service dependency, no daemon, no external API. There is no availability surface beyond the app itself.

Support

None. No upstream maintainer, no issue triage, no security advisories. Every defect is a first-party defect. This must be stated plainly to stakeholders — the 26 stars and 0 dependents mean the "we can Google the error" recovery path is effectively closed.

Scaling

• CPU-bound and memory-heavy. XML traversal and ZIP rewrite of a multi-sheet .xlsx can consume hundreds of MB. Large templates are the failure mode, not request volume.
• Scales horizontally via queue workers, which is the natural Laravel shape — generation should never run synchronously in a web request.
• No streaming; peak memory is a function of the largest single document. Enforce a per-job memory ceiling and a template size limit rather than discovering it in production.

Failure modes to design for

• Silent placeholder misses — a renamed data key produces a document with blank fields and no error. Requires post-render assertion on required placeholders.
• Corrupt or malformed template — engine throws opaque errors; wrap and translate into actionable messages naming the template version.
• Memory exhaustion on large spreadsheets — hard-fail the job with a clear reason, never retry-loop.
• Temp file leakage and cross-job contamination — isolated per-job temp directories with guaranteed cleanup in a finally.
• Encoding mangling — non-UTF-8 source data silently corrupts accented text; normalize at the boundary.
• Security — untrusted template uploads are an XXE/zip-bomb vector; treat template ingestion as a security boundary, not a convenience feature.

Ramp-up

• Engineering: low-to-moderate. The Laravel wrapper is trivial; the cost is the PHP 8 remediation and the vendoring discipline, which is unglamorous and easy to underestimate.
• Business users: moderate. TBS template syntax is niche and undocumented outside a single upstream manual — very few developers have seen it. Budget a written internal guide, a small set of canonical example templates, and a support channel, or template authoring will quietly revert to engineering.
• Organizational: the real ramp-up cost is accepting ownership. This package is a 2016 artifact with no maintainer; a TPM's recommendation should be adopt the engine, reject the bundle, and fund the fork explicitly — or choose a supported alternative now, while the cost of switching is still one proof of concept.