Common Bundle Laravel Package

Product Decisions This Supports

• Internal Framework Standardization: Accelerates development by providing reusable, opinionated base classes (e.g., BaseEntity, BaseUser) to enforce consistency across microservices or modules.
• Roadmap for Legacy System Modernization: Justifies adoption if migrating older PHP/Laravel projects to Doctrine ORM, reducing boilerplate for CRUD operations and timestamping.
• Build vs. Buy: Avoids reinventing common entity patterns (e.g., user profiles, lookup tables) but requires validation due to experimental status. Not a drop-in solution for production-critical systems.
• Use Cases:
  • Prototyping MVPs where rapid iteration outweighs stability risks.
  • Internal tools or non-customer-facing systems (e.g., admin panels, APIs).
  • Teams already using stof/DoctrineExtensionsBundle or doctrine/DoctrineFixturesBundle for fixtures/testing.

When to Consider This Package

Adopt if:

• Your team prioritizes speed over stability and can tolerate technical debt in non-critical projects.
• You’re building a monolithic Laravel app with shared entity patterns (e.g., user management, reference data) and want to avoid duplication.
• Your database is not SQLite (due to BaseLookup enum limitations) and you’re using Doctrine ORM with doctrine/doctrine-bundle.
• You’re willing to fork/maintain the package (given its broken state) or contribute to its development.

Look elsewhere if:

• Your project requires production-grade reliability (e.g., e-commerce, fintech).
• You need SQLite support or advanced enum handling (consider native Doctrine types or myclabs/deep-copy alternatives).
• Your team lacks bandwidth to debug/test experimental code.
• You prefer batteries-included solutions (e.g., Symfony’s MakerBundle, Laravel’s built-in Eloquent traits).

How to Pitch It (Stakeholders)

For Executives: "This package could cut 30–50% of boilerplate code for common database entities (users, timestamps, lookups) in our Laravel projects, accelerating feature delivery by 2–3x for non-critical systems. However, it’s not production-ready—think of it as a ‘beta’ framework for internal tools or prototypes. We’d need to allocate time to validate/stabilize it or explore alternatives like Symfony’s MakerBundle if reliability is critical."

For Engineering: *"The bundle provides:

• BaseEntity: Auto-timestamping and ID fields (replaces manual createdAt/updatedAt logic).
• BaseUser: Standardized user profiles (firstname, lastname, DOB) with Doctrine relationships.
• BaseLookup: Workaround for SQLite enum limitations via related entities.
• Test utilities: Base test cases for fixtures and database assertions.

Risks:

• Broken state: Requires triage before use (e.g., missing TODO docs, potential Doctrine version conflicts).
• Lock-in: Custom base classes may complicate future migrations.

Proposal:

1. Pilot: Use in a non-critical module (e.g., admin dashboard) to measure dev velocity gains.
2. Fork: Create a maintained fork if adoption makes sense, or replace with MakerBundle/Laravel Scout if needs evolve.
3. Alternatives: Compare to Laravel’s native traits or spatie/laravel-activitylog for audit trails.

Ask: Should we allocate 1–2 dev days to evaluate this for [specific use case]?"*