Terms Module Chromium Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for terms & consent management. The package bundles a Laravel "terms module" with a Chromium-based renderer, which maps directly to the classic build-vs-buy question for legal document lifecycle: drafting, versioning, publishing, acceptance capture, and immutable rendering. A PM can use it as a reference implementation to scope what "buy" actually includes (versioning, audit trail, re-acceptance on change, deterministic PDF evidence) versus what an in-house sprint would cost.
• Roadmap sequencing for compliance features. Concretely supports deciding whether Terms of Service / Privacy Policy versioning, per-user acceptance timestamps, and PDF snapshots ship this quarter or next. The Chromium angle implies deterministic, pixel-accurate PDF output — relevant when legal wants "the exact document the user signed."
• Rendering architecture decision. If the team is debating server-side PDF generation (headless Chromium) versus client-side print or a SaaS e-sign vendor, this is a working example of the headless-Chromium path inside a Laravel app, including the operational shape of that choice (queue workers, memory, container size, fonts).
• Use cases it unlocks: versioned T&C acceptance at signup, re-consent campaigns after policy updates, downloadable contract/statement PDFs, and archival snapshots for dispute resolution.
• Feature-level signal for a broader "documents" domain. If the roadmap includes invoices, KYC statements, or certificates, the same rendering + templating pattern is reusable, so evaluating this informs a platform-level capability rather than a one-off feature.
• New in v1.0.0 — the rendering layer is now explicitly a standalone component. The release note ("Initial version of Chromium Generator") indicates the Chromium rendering piece is being packaged as its own first-class artifact rather than an incidental dependency of the terms module. That strengthens the "evaluate the renderer on its own merits" angle: the PDF-generation decision (headless Chromium vs. SaaS vs. client-side) is now a decision you can make separately from the consent-tracking decision.
• Still a low-confidence signal, but no longer a stale one. The earlier read treated the package as abandoned (no release since October 2023). A v1.0.0 tag is a maintenance signal, not an adoption signal — treat this as prior art and a design input for an ADR, not a dependency bet.

When to Consider This Package

Consider it when:

• You are already inside the rich-id / rich.id ecosystem (the rich-id/* namespace and "bundle" naming suggest a first-party module for a specific platform), where it is presumably supported and versioned alongside the host application. This remains the single strongest reason to use it.
• You need a Laravel-native terms module with acceptance tracking and want to read or fork an existing implementation rather than start from a blank directory.
• You specifically want headless Chromium PDF rendering wired into Laravel and would rather vendor a small MIT-licensed example than assemble Browsershot/Puppeteer yourself — now more viable given v1.0.0 extracts the generator into a discrete component.
• You are doing due diligence / competitive scan and need to see how a peer modeled terms versioning in Eloquent, or how a peer packaged a Chromium generator for Laravel.

Look elsewhere when:

• You need a supported dependency. The v1.0.0 release improves the maintenance story but does not change the fundamentals: no evidence of community adoption, no independent dependents, and single-maintainer concentration risk. That is still disqualifying for anything customer-facing or legally load-bearing without a fork you own. Prefer maintained alternatives: spatie/browsershot or laravel/snappy for rendering; a first-party terms_versions + terms_acceptances schema for the domain logic; or a SaaS (Termly, Iubenda, DocuSign/HelloSign) if legal ops owns the workflow.
• You were consuming a pre-1.0 version. A v1.0.0 described as an "initial version" implies either a versioning reset or a rewrite of the Chromium generator. Treat it as a potential breaking change until you have diffed it: assume the API surface, config keys, and view/template contracts may have moved. Do not auto-bump.
• You need documentation and community answers. A version tag is not documentation. Expect to read the source, and expect the new 1.0.0 surface to be the least-documented part of it.
• Your Chromium runtime is a problem. Bundling Chromium means container bloat, memory pressure, sandbox flags, and font packages in your image — a real ops tax on constrained or serverless infrastructure. Extracting the generator does not reduce that tax; it just makes it more visible.
• You need SLAs, security review artifacts, or an indemnity path. MIT with no commercial backing provides none.
• You are not on the matching Laravel/PHP version. A freshly tagged 1.0.0 raises confidence in framework compatibility — but verify against your matrix rather than assuming, since the underlying code may be older than the tag.

Minimum gates before adoption: pin the exact 1.0.0 tag and audit the source, diff against whatever you evaluated previously for breaking changes, confirm Laravel/PHP compatibility against your matrix, verify license headers, check for a test suite (a 1.0.0 without tests is a yellow flag), and confirm the maintainer is reachable.

How to Pitch It (Stakeholders)

To executives (1 minute): We are evaluating how to handle terms-of-service versioning and PDF evidence — the "what did this customer actually agree to, and when" question that shows up in audits, disputes, and re-consent campaigns after a policy change. There is an open-source Laravel package that demonstrates one way to build this, including browser-grade PDF rendering, and it just shipped a 1.0.0 — a sign someone is still maintaining it, though not a sign anyone else is using it. My recommendation is unchanged: use it as a reference design and effort estimate, not as a dependency. The real decision is build-versus-buy: a focused internal build is likely 2–4 engineer-weeks for versioning, acceptance, and PDF snapshots, versus a recurring SaaS fee. The 1.0.0 slightly de-risks the estimate by making the rendering component cleanly separable, so we can price "render PDFs" independently of "track consent."

To engineering (the ask): Spend half a day on rich-id/terms-module-chromium-bundle at v1.0.0 as prior art — and treat the new Chromium Generator as a breaking change until proven otherwise; diff it against whatever we looked at before, don't just bump. Extract two things: (1) its Eloquent model for terms versions and acceptances, and (2) how the newly extracted generator drives Chromium inside Laravel, and whether it is now independently usable. Then give me an ADR with three options — build on spatie/browsershot + our own schema, buy a SaaS, or fork this package — with container-size, memory, queue, and font-packaging implications called out. Default assumption is build, borrowing patterns, not code; flag it if the fork is genuinely cheaper now that the generator is its own component.

Framing for the room: this is a compliance-capability investment with a clear audit-trail payoff, and the package is a cheap way to buy information before we buy or build anything. The 1.0.0 release is a reason to re-read it, not a reason to depend on it.