Laravel Sti Laravel Package

Product Decisions This Supports

• Domain modeling: one table or many? This package makes single table inheritance (STI) cheap to implement in Laravel — a base Eloquent model plus a discriminator column maps rows to subtype classes automatically on hydration. That turns "should these five things be one table with a type column, or five tables?" into a reversible, low-cost decision rather than a schema migration project.
• Roadmap sequencing for variant-heavy features. STI pays off when you have a family of near-identical entities that differ in behavior more than in data: notification channels, payment methods, content types (article/video/podcast), promotion types, line items, or workflow steps. It lets you ship a new variant as a new subclass — no migration, no new table, no changes to existing queries — which compresses the cost of "add another type" roadmap items.
• Build vs. buy vs. write-it-ourselves. At ~17 stars, 0 dependents, and a single release in April 2020, this is effectively source code, not a supported dependency. The realistic comparison is not "adopt vs. build a solution" but "vendor this ~200-line package vs. write a 50-line trait." For a PM, that means the decision hinges on whether the team wants a maintained-internally trait with tests, not on vendor evaluation.
• Query and reporting simplification. Cross-type dashboards, admin listings, and exports become single-table queries with WHERE type IN (...) instead of UNIONs across tables. This is a real, if modest, win for analytics and back-office tooling — worth flagging to whoever owns internal reporting.
• Architectural risk budgeting. The package implicitly endorses a schema where subtype-specific columns are nullable and shared. That is a decision with long tails: every new subtype widens the table, and database-level NOT NULL constraints stop being available for subtype fields. The PM should treat this as an explicit trade — development speed now, schema tidiness later — and set a tripwire (e.g., "when a subtype adds more than three exclusive columns, revisit").
• Not supported by this package: polymorphic relations across genuinely different tables, subtype-specific foreign keys, or anything requiring DB-level integrity per subtype. Those remain separate decisions.

When to Consider This Package

Consider it when:

• The app is pinned to a Laravel version contemporary with the package's last release (Laravel 6/7 era, PHP 7.x), or the team has verified it works on your stack. Eloquent internals around hydration and instance construction have changed since 2020, so this is a must-check, not a formality.
• Subtypes share the large majority of their columns and differ mainly in behavior (methods, scopes, validation rules, presentation).
• Queries routinely span all subtypes — admin lists, feeds, exports — so a single table is a genuine performance and simplicity win.
• The team is small, comfortable reading Eloquent internals, and can own a fork.
• The feature area is internal or low-blast-radius, so an unmaintained dependency cannot become a production incident.

Look elsewhere (or write your own trait) when:

• You are on Laravel 9/10/11/12 or PHP 8.2+. Treat compatibility as unproven until someone has run the test suite; the safer plan is a fork you control.
• Subtype-specific columns are numerous, frequently added, or need NOT NULL / per-subtype foreign keys. Separate tables or a JSON attributes column will age better.
• You need polymorphic relations across distinct entities — Laravel's native morphTo/morphMany is the right tool, and this package is not a substitute.
• Your organization requires a supported dependency with a security-response path, an active maintainer, or an SBOM entry with version cadence. Zero dependents and a two-year-old release are hard signals to argue past.
• The domain is core to the business and expected to diverge over time. STI is an optimization for convergence; if subtypes are on a path to becoming independent aggregates, you are borrowing against future rework.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed open-source helper that lets our Laravel code model a family of similar things in one database table while still giving each type its own class and behavior. It is not a platform or a vendor commitment — it is roughly source code we would otherwise write ourselves. Cost is near zero; the risk is also the reason to be careful: it has 17 GitHub stars, no downstream dependents, and has not been released since April 2020, so we should treat it as code we own rather than a dependency we consume. Recommendation: adopt only inside a bounded feature area, vendor it into our repo, add tests, and pair the decision with a written threshold for when we split the table.

To engineering: The package gives us STI on Eloquent — a base model and a discriminator column, with subclass resolution on hydration — which removes the boilerplate of hand-rolling newFromBuilder overrides and type maps. The trade is that it is unmaintained and last shipped against a 2020-era Laravel, so plan on forking and testing against our current version, and be deliberate about the parts STI does not solve for free: factories, form requests and validation per subtype, eager-loading behavior, and the fact that subtype columns must stay nullable. If the fork cost feels higher than the payoff, a short internal trait gets us 90% of the value with none of the dependency risk — that is a reasonable outcome, and we should decide it on the basis of how many subtypes we actually expect.