Datatable Bundle Laravel Package

Product Decisions This Supports

• Theming and white-labeling roadmap bets. The new public theme registry with immutable metadata, explicit capability declarations, and asset ownership turns "Bootstrap look" into a swappable contract. This is the enabling capability for multi-brand deployments, per-tenant styling, and design-system alignment — decisions that previously would have required forking templates or a custom build.
• Build vs. buy on presentation layer. Because shells, partials, and typed-cell templates now all resolve through the selected theme, we can buy the table/search machinery and keep only our theme as bespoke code. That shrinks the surface area we own and makes the buy case materially stronger than in 1.x, where customizing presentation meant touching package internals.
• Front-end stack independence. Decoupling the Stimulus controller from Bootstrap-specific imports and generated classes means the package no longer forces Bootstrap on us. This unblocks a decision to standardize on a different CSS framework or a utility-first design system without abandoning the table/search functionality.
• Security and compliance posture. Replacing HTML interpolation with DOM nodes and textContent in the dynamic Search Builder closes a class of injection risk in user-driven query construction. That is a directly citable item for security review and for any customer-facing questionnaire about input handling.
• External theme distribution as a product option. Fresh-host validation of a complete external theme package implies themes can be shipped and installed as discrete artifacts — a prerequisite if we ever want customer- or partner-authored themes, or themes as a paid/optional module.
• Upgrade timing and support-window planning. This is a 2.0 beta with explicit breaking changes and a migration guide, so it becomes a scheduled line item with a defined exit from 1.x rather than an opportunistic bump.

When to Consider This Package

Adopt when:

• The product is a Laravel application rendering data-dense, server-driven tables with filtering, search, and typed cell presentation — this is the package's center of gravity.
• A single maintained theme (Bootstrap by default) is acceptable at launch, and you want a documented, supported path to introduce additional themes later without forking.
• You are starting fresh or are pre-2.0; the theme registry is cheapest to adopt before you have accumulated template overrides.
• You need the dynamic Search Builder, and its hardened construction is relevant to your threat model or review requirements.
• You want a stable, small set of maintained front-end assets rather than owning a table UI from scratch.

Look elsewhere or defer when:

• You are deep into 1.x with heavy template overrides and custom cell presentation. The migration touches template override, asset, and confirmation-dialog behavior simultaneously; budget for it or stay on 1.x until a stable 2.0 lands.
• You require a GA-quality release. This is 2.0.0-beta.1; APIs around theme metadata and capabilities may still shift before final.
• Your front end is Inertia/SPA or heavily client-side. The package's value is server-driven rendering; the Stimulus decoupling helps, but it does not make this a client-side table library.
• You need a non-Bootstrap theme on day one and cannot self-author one against the new registry contract — only Bootstrap is a maintained theme.
• You need vendor-backed SLAs or a formal long-term support commitment; this is a community package, and the 2.0 line is pre-stable.
• Your primary need is charting, pivots, or export-heavy reporting — evaluate adjacent tooling first rather than stretching this one.

How to Pitch It (Stakeholders)

For executives: This release converts a Bootstrap-tied component into a themeable one. Practically, it means we can serve multiple brands or tenants from a single codebase with our own styling as a contained, replaceable artifact instead of a fork — a meaningful reduction in long-term maintenance cost and a faster path to white-label and design-system work. It also hardens user-supplied search input against script injection, which is a clean win for security review and customer due diligence. The tradeoff is that this is a beta with documented breaking changes; treating it as a deliberate, scheduled upgrade rather than an incidental one keeps the risk bounded and keeps us on a supported path.

For engineering: The 2.0 line introduces a public theme registry — immutable metadata, declared capabilities, and asset ownership — with fresh-host validation of a full external theme package. Every shell, partial, and typed-cell template now resolves through the selected theme, and default cell presentation moved into BootstrapTheme. The Stimulus controller no longer imports Bootstrap-specific code or relies on generated classes; confirmation uses native <dialog> and dynamic controls consume theme-supplied classes. Search Builder construction now builds DOM nodes and uses textContent rather than HTML interpolation. Net effect: presentation is a contract we can implement once, our CSS framework is no longer dictated by the package, and one injection vector is gone. Cost is a coordinated migration — template overrides, assets, and confirmation dialogs all change together — so plan it as one unit against the migration guide, and pin to the beta only behind a feature flag until 2.0 is stable.